おはようございますこんにちはこんばんは。 キューのWebチームで、ディレクターをしている田辺です。

我々Webチームでは、Shopifyのアプリ開発に取り組んでいます。 私は、Shopifyのアプリ開発にディレクターという立場で関わっているのですが、 ふと、「こういう機能は実装できないか？」と思い立つことがあります。

そんなとき、それができるかどうかを、いちいちエンジニアに聞くのが面倒くさい、、、ではなく、彼らの手をその都度、止めてしまっては生産性の向上は望めません。

そこで、自分でShopifyのAPIコールを試せれば、少なくとも一次調査くらいはできるなと思い立ち、Postmanを使ってShopify APIを手軽に試せる環境(というほど大袈裟なものではありませんが)を作ってみたので、本記事ではその紹介をします。

この記事の存在意義を根底から揺るがす「はじめに」

Shopifyには、Shopify Admin API (GraphQL)とストアフロントAPI(GraphQL)を自由にテストできるWebツールやアプリがあります。

Webツール:<a href="https://shopify.dev/apps/tools/graphiql-admin-api" target="_blank" rel="noopener">&nbsp;https://shopify.dev/apps/tools/graphiql-admin-api</a> Shopifyアプリ:&nbsp;<a href="https://shopify-graphiql-app.shopifycloud.com/login" target="_blank" rel="noopener">https://shopify-graphiql-app.shopifycloud.com/login</a>

これらのツールやアプリを使った方が、断然楽ですので、GraphQLだけ触ってみたい方は、これで十分です。

それでも、PostmanにこだわりたいPostman Loverな方や、REST APIも触ってみたいなどのご要望がある方は、記事を読み進めていただけると幸せになれることもあるかもしれません。

<code class="inline-code">MacOS</code> <code class="inline-code">Postman 9.25.0</code>

Web APIをテストするツール、という認識でほぼ間違いありません。クラウド版もありますが、今回はデスクトップアプリ版を使用します。 Postmanの詳細についてより詳しく知りたい方や、ダウンロード方法を知りたい方は下記をご覧ください。

Postmanとは:&nbsp;<a href="https://ugo.tokyo/about-postman/" target="_blank" rel="noopener">https://ugo.tokyo/about-postman/</a> Postman デスクトップアプリのダウンロード:&nbsp;<a href="https://www.postman.com/downloads/" target="_blank" rel="noopener">https://www.postman.com/downloads/</a>

PostmanによるShopify APIのテスト環境を作る

手順1. Shopifyの開発ストアを用意する

もちろん、開発ストアではなく実際に運用されているストアを使用しても問題ないですが、Shopify APIは、ストアの情報を変更することも可能なので、思わぬ事故を防ぐためにも、開発用のストアを別途準備することをおすすめします。

Shopifyのパートナープログラムに登録(無料)すると、開発用のストアを無料で作成できます。 まず、Shopifyのパートナープログラムに登録しましょう。 登録は、当ブログの下記の記事を参考にすると簡単です。

<a href="https://techlab.q-co.jp/articles/44/#%E9%96%8B%E7%99%BA%E3%83%95%E3%83%AD%E3%83%BC" target="_blank" rel="noopener">Shopifyアプリの開発フローと準備　開発フロー</a>

記事内の、「パートナーアカウントの作成」と「開発ストア」の設定を行い、開発ストアを用意します。

手順2. 開発ストアにカスタムアプリを作成し、APIのアクセストークンを2種類取得する

開発ストアの管理画面にアクセスし、下記の手順に沿って、設定していきます。

今回、取得した、Admin APIのアクセストークンと、ストアフロントAPIのアクセストークンを使って、Postmanから、Shopify APIをコールします。

手順3. Postmanのコレクションを設定する

準備する変数は下記になります。 INITIAL VALUEにも、CURRENT VALUEにも同じ値を設定いただけば問題ありません。

入力完了後、忘れずに設定を保存します。(MacOSであれば、Command+Sで保存されます。)

手順4. Admin APIをテストするサンプル

まず、下図のようにして新しいリクエストを作成します。

作成したリクエストを選択し、POSTを選択したら、下記のURLを設定します。 <code class="inline-code">https://{{DEV_STORE}}.myshopify.com/admin/api/{{API_VERSION}}/graphql.json</code>

Headersを選択し、次のリクエストヘッダーを追加します。 KEY: <code class="inline-code">X-Shopify-Access-Token</code> VALUE: <code class="inline-code">{{SHOPIFY_ACCESS_TOKEN}}</code>

Bodyを選択し、GraphQLを選んだら、下記の内容をQUERYにセットします。

Sendをクリックし、APIコールを実施するとレスポンスが得られます。 今回セットしたQUERYからは、開発ストアのIDと名前を取得できます。

手順5. ストアフロントAPIをテストするサンプル

手順4と同様に、下図のようにして新しいリクエストを作成します。

作成したリクエストを選択し、POSTを選択したら、下記のURLを設定します。 ※Admin APIとはURLが異なりますのでご注意ください。 <code class="inline-code">https://{{DEV_STORE}}.myshopify.com/api/{{API_VERSION}}/graphql.json </code>

Headersを選択し、次のリクエストヘッダーを追加します。 ※こちらもAdmin APIの時とは値がそれぞれ異なりますのでご注意ください。 KEY:&nbsp;<code class="inline-code">X-Shopify-Storefront-Access-Token</code> VALUE:&nbsp;<code class="inline-code">{{SHOPIFY_STOREFRONT_ACCESS_TOKEN}}</code>

Sendをクリックし、APIコールを実施するとレスポンスが得られます。 Admin APIの時と同様、今回セットしたQUERYからは、開発ストアのIDと名前を取得できます。

いかがでしたでしょうか？ バッチリAPIのレスポンスは取得できたでしょうか？

本記事では、Admin APIやストアフロントAPIのアクセストークンの説明や、GraphQLの説明を割愛し、「こうすればPostmanからShopifyのAPIをコールできる」という手順のみのご紹介でした。

本記事をきっかけにShopify APIに興味を持ってくださる方がほんの少しでも増え、Shopifyの開発がますます盛り上がれば幸いです。

他のAPIを試す場合は、手順4や手順5の、「BodyのQuery」に入力する内容を変更するだけで問題なくAPIコールできるはずです。

最後に、ShopifyのAdmin APIとストアフロントAPIのリファレンスを付記いたしますので、気になるAPIがありましたら是非お試しください。

Shopify Admin API reference:&nbsp;<a href="https://shopify.dev/api/admin-graphql" target="_blank" rel="noopener">https://shopify.dev/api/admin-graphql</a> Shopify ストアフロントAPI reference:&nbsp;<a href="https://shopify.dev/api/storefront" target="_blank" rel="noopener">https://shopify.dev/api/storefront</a>

ShopifyのAPIをPostmanで手軽にテストする

gitのコミット時にコードの変更部分に対して、自動でフォーマットを行う仕組みを導入しました。 そもそも、なぜコードフォーマッターが必要なのかは、 ・ソースコードのスタイルの一貫性を保つため ・コードの構文チェックも行い、コードを実行する前に明らかなバグなど検出できるようにしたい ・Pull Request（以降PR）時にコードスタイルの指摘修正をなくすため ・ツールを導入することにより、手動で修正する手間をなくすため 以上、4点になります。 コードフォーマッターのLintのライブラリとして、PrettierとESLintの両方を導入しました。 本記事では、Prettier + ESLintを併用する理由、導入した仕組みの説明と導入した感想についてご紹介します。

<code class="inline-code">Node.js 16.13.0</code> <code class="inline-code">npm 8.10.0</code> <code class="inline-code">React 17.0.2</code> <code class="inline-code">typescript 4.6.4</code>

コードフォーマットについて ・Prettierはソースコードを整形してくれるツール ・ESLintはソースコードの整形する機能だけでなく、ソースコードの構文チェックを行えるツール PrettierとESLintを併用する理由 ・PrettierはESLintよりコードの整形に優れている ・ESLintはコードの構文チェックを担保できる 以上の2点からコードの整形とコードの構文チェックの両方担保したく、PrettierとESLintを併用することにしました。 PrettierとESLintの役割について ・Prettier:&nbsp; コードの整形を担当し、コーディングスタイルを一定に保つ役割 ・ESLint: コードの構文チェックを担当し、コードを実行する前に明らかなバグなど検出する役割

・<code class="inline-code">prettier-eslint</code>をインストール <code class="inline-code">prettier-eslint</code>はprettierとeslintを連携するためのパッケージです。

Prettierのルールを記述します。 ESLintと併用する以上、Prettierのルールは最低限に設定します。 そうしなければ、最低限に設定しないとPrettierとESLintの修正で競合が発生してしまうからです。 <code class="inline-code">.prettierrc</code>をプロジェクトルート配下に作成します。 [参照]&nbsp;<a href="https://prettier.io/docs/en/options.html" target="_blank" rel="noopener">https://prettier.io/docs/en/options.html</a>

<code class="inline-code">eslint</code>をインストールします

<code class="inline-code">eslint</code>のプラグインをインストールします。

インストールしたパッケージのversionが下記一覧になります。

プロジェクトルート配下に<code class="inline-code">.eslintrc.js</code>を作成し、設定を記述します。 ESLintのルールの記述はベースのルールを定義後、上書きしたいルールを記述します。 ベースのルールは<code class="inline-code">extends</code>配下に記述し、上書きしたいルールを<code class="inline-code">overrides</code>配下に記述します。 ベースのルール、上書きしたいルールの選定はプロジェクトの環境・状況・要件に合わせてください。 下記は記述例になります。 [参照]&nbsp;<a href="https://eslint.org/docs/rules/" target="_blank" rel="noopener">https://eslint.org/docs/rules/</a>

<code class="inline-code">.eslintignore</code> にESLintの実行を無視するディレクトリ（ビルド出力など）を定義します。

pre-commitの場合だけ特定のルールを緩和したい場合

別途<code class="inline-code">.eslintrc.pre-commit.js</code>を作成し、緩和したいルールを記述します。 実際のファイルの書き方の例が下記になります。

コミット時にコードの変更部分に対して、Prettier と ESLint が実行されるようにする

上記の設定でコードの整形と構文チェックを可能となりましたが、PrettierとESLintを実行しない限りはコードの整形・構文チェックは行われません。PrettierとESLintを実行せず、PRを提出してしまう人が出てきてしまいます。これだとコードの品質が保てません。 コードの品質を保てるよう、コミット時にPrettierとESLintを実行できるようにします。 Gitには、pre-commitというコミットの前に指定のスクリプトを実行できる仕組みがあります。 今回はpre-commitを利用し、pre-commit時にPrettierとESLintを実行できるようにします。

pre-commitに必要なパッケージをインストール

<code class="inline-code">husky</code>と<code class="inline-code">lint-staged</code>をインストールします。

・<code class="inline-code">husy</code>はGit commit時やpush時に指定したコマンドを実行できるライブラリになります。 ・<code class="inline-code">lint-staged</code>はGitのステージングに追加されたファイルにのみPrettierやESLintなどのリントを実行できるライブラリになります。 [参照] <a href="https://github.com/okonet/lint-staged" target="_blank" rel="noopener">https://github.com/okonet/lint-staged</a> <a href="https://github.com/typicode/husky" target="_blank" rel="noopener">https://typicode.github.io/husky/#/ </a>

Git フックを有効にします。 実行後、<code class="inline-code">.husky</code>ディレクトリと<code class="inline-code">.husky.sh</code>が作成されます。

コマンドを実行すると、<code class="inline-code">package.json</code>の<code class="inline-code">scripts</code>配下に<code class="inline-code">prepare</code>が追加されます。

<code class="inline-code">pre-commit</code>のフックを追加します。

上記を実行すると<code class="inline-code">.husky/pre-commit</code>が作成されます。 <code class="inline-code">.husky/pre-commit</code>の中身は下記の内容になります。

<code class="inline-code">lint-staged.config.js</code>を作成します。 <code class="inline-code">js,jsx,ts,tsx</code>ファイルに対して、PrettierとESLintのコマンドと対象ファイル・ディレクトリを記述します。

・<code class="inline-code">prettier --write</code>:対象ディレクトリのファイルをPrettierが全てフォーマット ・<code class="inline-code">eslint --cache --config .eslintrc.pre-commit.js --fix --quiet&nbsp; </code><code class="inline-code">--cache</code>:&nbsp;変更されたものだけを操作するために、処理されたファイルに関する情報を保存するフラグ <code class="inline-code">--fix</code>:&nbsp;コードに自動修正を行うフラグ <code class="inline-code">--quiet</code> :&nbsp;警告に関する報告を無効にするフラグ <code class="inline-code">--config</code>:&nbsp;<code class="inline-code">.eslintrc.js</code>ではなく、別途ファイルを読み込みたい場合のフラグ。今回であれば、<code class="inline-code">.eslintrc.pre-commit.js</code>が当たります。 [参照]&nbsp;<a href="https://eslint.org/docs/user-guide/command-line-interface" target="_blank" rel="noopener">https://eslint.org/docs/user-guide/command-line-interface</a> ESLintよりPrettierを先に実行する理由は、ソースコードが整形された状態でソースコードの構文チェックを実行したいためです。先にPrettierを実行した上でESLintを実行した方がより確実に構文チェックを行えます。 以上の設定で、コミット時にPrettierとESLintが実行できるようになりました。 実際にコミットを実行してみます。 何らかのESLintのルールに引っかかり、コミットできなくなると、下記のようになります。

エラーになった場合は、エラーを解消しなければ、コミットはできません。 ESLintのエラーとなる箇所を修正し、ESLintのチェックが通ると、コミットができます。 コミット成功時は下記のようになります。

コミット時にPrettierとESLintが実行されることにより、コードの品質が一定水準以上に保つつことができました。また、インデントの修正などコードのスタイル修正に割く作業が無くなったことも大きな収穫でした。手軽に導入できましたので、導入して大変良かったです。少しでも魅力と感じられましたら、導入をお勧めします。

以上、コミット時にコードの変更部分に対して、フォーマットをかける仕組みと導入した感想についてご紹介しました。PrettierとESLintの導入を検討している方のご参考になれば幸いです。

gitのコミット時にコードの変更部分に対して、自動でフォーマットを行う

前編はこちら: <a href="http://https;//techlab.q-co.jp/articles/51/" target="_blank" rel="noopener">https;//techlab.q-co.jp/articles/51/</a> 前編では、dokkuのインストールからアプリケーションをデプロイするところまで行いました。 本記事ではデプロイをGithub Actionsで行う設定を紹介します。

dokkuのガイドではアプリケーション(app)は１レポジトリ１コンテナの対応で、`dokku git:set` によってそのデプロイ対象ブランチを切り替えるという想定のセットアップになっていました。 ここから主目的である、すべて同じアプリケーションで違うブランチという構成に設定していきます。 まずは、いくつかの下準備をします。

Dockerのディレクトリを外部ボリュームに移動

Dockerはイメージなどで容量が必要なので元の8GBでは足りなくなります。そのためDockerの使うディレクトリを外部ボリュームに移動させます。 下記リンクのチュートリアルに従って移動してください。サービスやOSが違う場合は適宜読み替えてください。 チュートリアル:&nbsp; <a href="https://dokku.com/docs/community/tutorials/run-on-external-volume/" target="_blank" rel="noopener">https://dokku.com/docs/community/tutorials/run-on-external-volume/</a> AWS Docs:&nbsp; <a href="https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html" target="_blank" rel="noopener">https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html</a>

使っていくと不要になったイメージなどがどんどん溜まっていくので、削除するcronをあらかじめ設定しておきます。

Github Actionsの処理の中でSSHキーが必要になります。 レポジトリの Settings -&gt; Secrets -&gt; Github Actions を開き、インスタンスにログインするものと同じプライベートキーを登録してください。インスタンス作成時と別のものを使う場合はインスタンスへの登録に加えて、dokkuへの登録も改めて必要になります。

また、インスタンスのファイアウォールが有効な場合、Github ActionsからDokkuサーバーへのアクセスを許可する必要があります。 <a href="https://docs.github.com/ja/rest/meta#get-github-meta-information" target="_blank" rel="noopener">https://docs.github.com/ja/rest/meta#get-github-meta-information</a>&nbsp;から使われる可能性のあるIPアドレスのリストを取得できます。大量なので少し時間がかかるかもしれません。

本題のPRごとにする設定をします。 <a href="https://github.com/dokku/github-action/blob/master/example-workflows/review-app.yml" target="_blank" rel="noopener">https://github.com/dokku/github-action/blob/master/example-workflows/review-app.yml</a> dokkuが用意している Github ActionsプラグインにPreview App というPR向けの機能が用意されているのでこちらを元に設定します。

アプリケーションのルートに .github/workflows/pull_request.yaml を作成します（ファイル名は任意） ドメイン、鍵の名前等を適宜自身の環境に合わせて変更してください。 以下に示す設定では、コンテナはGithubのPR番号をとって、pr-1, pr-2 のような名前で作成されます。( ＝サイトは https://pr-1.dokku.yourdomain.com ) review_app_name: pr-${{ github.event.pull_request.number }} で任意に変更可能です。（変更した場合、SSHで domains:set をする場所も変更してください。）

目的はPR用のサーバーですが、メインのブランチも一緒に運用していく場合はプッシュ用のActionも作ります。 .github/workflows/push-main.yaml

・新しいブランチを作って適当な変更を加えてプッシュし、プルリクエストを作ってサーバーが起動する ・更に適当な変更を加えてプッシュし、変更点が反映される ・プルリクエストをマージしmainのサーバーが更新される（push-mainを作った場合）

以上を確認できたら、完成です。

プルリクエストに連動したCI/CDサーバーを立てる例です。

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　後編

レポジトリ運用において、変更が承認されマージされたらサーバーにデプロイされる仕組みは既に多くの方が取り入れていると思います。 しかし、マージ前（＝プルリクエスト）の状態でそのコードを反映したアプリケーションをサーバーに上げられると、確認環境として共有したり数パターンの変更を並べて見ることができたりと便利です。本記事では、Dokkuを用いたプルリクエスト連動CI環境の作成を紹介します。 Dokkuとは、アプリケーションのデプロイ環境を手軽に作成できるPlatform as a Service (PaaS)です。オープンソースであり、無料で利用できます。DokkuとGithub Actionsと合わせることで比較的簡単にこのCI環境を作成できます。 公式サイト Dokku&nbsp;<a href="https://dokku.com/docs/getting-started/installation/" target="_blank" rel="noopener">https://dokku.com/docs/getting-started/installation/</a> Github Actions&nbsp;<a href="https://docs.github.com/ja/actions" target="_blank" rel="noopener">https://docs.github.com/ja/actions</a>

Dokkuをインストールするためのサーバーを起動します。 本記事ではAWS EC2インスタンスを使います。GCP等別のサービスを使う場合は適宜読み替えてください。

Dokkuのドキュメント上の要求スペックは1GB RAMと書かれていますが、アプリケーションコンテナを複数起動するので実際はもっと多いほうがいいです。アプリケーションやチームの大きさ・利用頻度に合わせて変更してください。 またDockerはストレージを結構使うので、追加のストレージが必要になります。利用頻度にもよりますが、128GBくらいはあった方がいいと思います。（ちなみに当社では t3.large + 128GB です）

Dokkuをホストするサーバー用にドメインを用意します。持っていない場合はお名前.com、Route53などのDNSサービスで取得してください。 更に、今回のDokku用のサブドメインを作成します。管理画面から、先ほど起動したサーバーのIPアドレス宛に <code class="inline-code">dokku.yourdomain.com</code>, <code class="inline-code">*.dokku.yourdomain.com</code>&nbsp;（以下、サンプルではこのドメインで進めます）のAレコードを作成します。

まずは公式ドキュメントに沿ってインストールを進めます。（　<a href="https://dokku.com/docs/getting-started/installation/#getting-started-with-dokku" target="_blank" rel="noopener">https://dokku.com/docs/getting-started/installation/#getting-started-with-dokku</a>　） インスタンスにSSHでログインした後、Dokkuをインストールします。

次に、ローカルでデプロイするサンプルのアプリを作成します。 サンプルとしては create-next-app （&nbsp;<a href="https://nextjs.org/docs/getting-started" target="_blank" rel="noopener">https://nextjs.org/docs/getting-started</a> ）等で構いません。が、ちゃんとしたアプリがあればそちらを使ってもいいです。 作成したら、githubにもレポジトリを作ってこのアプリケーションをプッシュしておきます。

他にもいくつか方法がありますが、今回は基本となる「サーバー上にクローンしたレポジトリに変更をプッシュする方法」でdokkuサーバーにデプロイします。後ほどGithub Actionsの設定を行いますが、試しにmainブランチを手動デプロイしてみます。

pushのログが⇡ のように出れば成功です。 <code class="inline-code">http://&lt;レポジトリ名&gt;.dokku.yourdomain.com</code> にアクセスするとサンプルアプリのホーム画面が出ているはずです。

そのままだとhttpなので、Let's EncryptでSSL化します。 Dokkuがdokku-letsencryptというプラグインを用意しています。ワイルドカードが未サポートの様ですが（issueの投稿によればサポートする可能性はあるようです）、自動でやってはくれるので、少々汚いですがブランチごとにこのプラグインで取り直す形を取ります。 （別で取得した場合は certs:add します。詳しくは <a href="https://dokku.com/docs/deployment/application-deployment/#setting-up-ssl" target="_blank" rel="noopener">https://dokku.com/docs/deployment/application-deployment/#setting-up-ssl</a> ）

改めて&nbsp; <code class="inline-code">https://&lt;レポジトリ名&gt;.dokku.yourdomain.com</code>&nbsp;にアクセスして、鍵マークが付いていれば完了です。 後編ではGithub Actionsとの連携を設定します。

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　前編

Shopify アプリことはじめ 3回目に当たる今回は、実際にアプリの開発作業に入っていきます。

前回記事より開発フローを再掲します。

開発の項目に関しては、ShopifyのUIライブラリであるPolarisによる管理画面の作り方と、Shopify GraphQLを利用したリソースの管理に分割してご紹介していきます。

本シリーズでは「指定タグのついた注文情報を発送済にする」アプリを作っていきます。<a href="https://shopify.dev/apps/getting-started/add-functionality" target="_blank" rel="noreferrer">Shopifyの一番最初のハンズオン</a>は商品の価格を変更するアプリです。なのでせっかくですので別のリソースを使ったアプリをサンプルにします。

まずはGraphQLを利用したリソース管理から紹介したいのですが、今回はその準備としてリファレンスやツールの紹介とテストデータの準備を行います。

ShopifyはいくつかのAPIを有しておりますが、商品情報や注文情報を管理したい場合はAdmin APIを利用します。Admin APIはインターフェイスとしてGraphQLとRESTの二つが用意されています。

本シリーズではGraphQLを使ってアプリを作ります。なぜなら、そちらの方が楽しいからです。

RESTの方が好みだという方もいらっしゃると思います。そのような方でも追いやすいように、RESTではどこのリファレンスを参照すれば良いかをご紹介し、GraphQL同様に進めていけるようにします。

リソース取得に使うquery、リソースの追加・更新・削除などに使うmutation、そしてそれぞれで扱われるobjectに関しての説明はこちらで確認できます。

<a href="https://shopify.dev/api/admin-graphql" target="_blank">https://shopify.dev/api/admin-graphql</a>

RESTの場合はこちらを参照してください。GraphQLを使用している場合でも一部のfilterなどで使える値をこちらで確認するケースもありました。

<a href="https://shopify.dev/api/admin-rest" target="_blank">https://shopify.dev/api/admin-rest</a>

queryやmutationのテストが行えます。

<a href="https://shopify.dev/apps/tools/graphiql-admin-api" target="_blank">https://shopify.dev/apps/tools/graphiql-admin-api</a>

Explorerタブをクリックすると、左側にGraphQLクエリの一覧が表示されます。使用したいGraphQLクエリ、レスポンスに欲しい値をなどをクリックしていくことで、GraphQLクエリを作成してくれます。

mediaLibraryStrapi

PreviewタブをクリックすることでGraphQLクエリの整形もしてくれます。完成したら再生ボタンを押すことで、サンプルのレスポンスを確認することが出来ます。何かミスがあればエラーも確認することが出来ます。

ストアスタッフが取得したいタグを複数入力すると、条件に合った注文の一覧が表示されます。「発送済にする」ボタンをクリックすると、対象の注文が逐次発送済ステータスになります。

上記の要件から以下の2点が必要だと考えられます。

注文検索時に1を実行し注文一覧を取得、ボタンクリックで2を実行し対象の注文を発送済ステータスに変更するという流れです。

GraphQL Admin APIを触る前に、下準備をしておきましょう。

ShopifyではCLIを通して、複数のテストデータを作成することが出来ます。では注文を作成していきます。

shopify populateは指定したリソースを作成するコマンドです。正確には注文を直接作成することはできないので、注文の下書き(draftorder)を作ります。他にも商品(product)や顧客(customer)のデータを作ることが出来ます。

nオプションは作成するリソースの件数です。未指定の場合は5件作成されます。

作成した注文の下書きは、ストア管理画面の「注文管理」→「下書き」から確認できます。このままではテスト出来ないので、支払いを回収し注文に変換していきます。CLIから変更はできないので、ストア管理画面から対象の注文の下書きを選択し、GUIで変更していきます。

詳細画面の「支払いを回収」ボタンをクリックし、「支払い済みとしてマークする」を選択してください

確認用のモーダルが表示されますので、そのまま「注文を作成」ボタンをクリックすると、注文が作成されます。

次に作成するアプリがストア内のリソースを操作できるように、スコープを指定します。スコープを指定することで、アプリインストール時にストアスタッフに指定スコープを承認するかの確認が表示されるようになります。

今回必要となるスコープは以下です。

ルートディレクトリ直下にある<code class="inline-code">.env</code>に必要なスコープを,繋ぎで記述してください。

既にアプリがインストールされていた場合でもスコープが更新されると、アプリ表示時に再度確認画面が表示されます。ストアの管理画面から作成中のアプリに移動し、承認を行なってください。

作成するアプリにどのようなスコープが必要か確認したい場合は、リファレンスを参照します。必要スコープの記述は各mutationやobjectの仕様ページにあります。

例えば今回は、orderオブジェクトを取得するので、以下のページで確認します。

<a href="https://shopify.dev/api/admin-graphql/2022-04/objects/Order#top" target="_blank">https://shopify.dev/api/admin-graphql/2022-04/objects/Order#top</a>

RESTの場合は各リソースの使用ページにCautionの形で記述されています。

<a href="https://shopify.dev/api/admin-rest/2022-04/resources/order#top" target="_blank">https://shopify.dev/api/admin-rest/2022-04/resources/order#top</a>

長くなってしまいましたので、今回は一旦ここまでとします。GraphQLを利用するのに必要なリファレンス・ツールの紹介をしました。また、開発時に使用するテストデータの作成と、アプリのスコープの設定を行いました。

次回はApollo Clientを用いてGraphQLでShopifyのリソースを管理する方法を紹介します。

Shopifyアプリをnodeで作成していくシリーズ

Shopifyアプリことはじめ

Shopify アプリ開発(GraphQL準備編)

CSSプロパティの<code class="inline-code">aspect-ratio</code>は一部のブラウザで非対応なので、スタイルを当てるために別途実装が必要な場合があります。その実装方法として、<code class="inline-code">@supports</code>を利用した方法をご紹介します。

後述しますが、<code class="inline-code">@supports</code>はIE11で非対応なので、IE11をサポートする場合は使えません。

aspect-ratioはCSSのプロパティで、要素に対してアスペクト比を設定することができます。 例えば、画像でアスペクト比を固定したい場合に役立ちます。レスポンシブにアスペクト比を固定してくれるので余計な設定をする必要がありません。

<a href="https://developer.mozilla.org/ja/docs/Web/CSS/aspect-ratio" target="_blank" rel="noopener">https://developer.mozilla.org/ja/docs/Web/CSS/aspect-ratio</a>

@supportsはCSSの<a href="https://developer.mozilla.org/ja/docs/Web/CSS/At-rule" target="_blank" rel="noopener">アットルール</a>で、機能クエリと呼ばれます。 CSSのプロパティがブラウザにサポートされているかによって、宣言を指定することができます。

<a href="https://developer.mozilla.org/ja/docs/Web/CSS/@supports" target="_blank" rel="noopener">https://developer.mozilla.org/ja/docs/Web/CSS/@supports</a>

<code class="inline-code">aspect-ratio</code><code class="inline-code">@supports</code>の互換性を見ていきます。互換性は「<a href="https://caniuse.com/" target="_blank" rel="noopener">Can I use</a>」で確認します。 <code class="inline-code">aspect-ratio</code>は一部のSafariで使えませんが、<code class="inline-code">@supports</code>を利用して実装できることが分かります。

・aspect-ratio [<a href="https://caniuse.com/mdn-css_properties_aspect-ratio" target="_blank" rel="noopener">https://caniuse.com/mdn-css_properties_aspect-ratio</a>]

・@supports [<a href="https://caniuse.com/css-featurequeries" target="_blank" rel="noopener">https://caniuse.com/css-featurequeries</a>]

例として Sass の mixin を利用しています。

アスペクト比 16:9 を設定したい場合は、このように使います。

アスペクト比を設定するので、<code class="inline-code">width</code><code class="inline-code">height</code> を受け取るように定義しています。

<code class="inline-code">aspect-ratio</code>のスタイルを定義しています。サポートされているブラウザではこちらのスタイルが当たります。

<code class="inline-code">@supports not ()</code>を使って<code class="inline-code">aspect-ratio</code>が使えない場合のスタイルを定義しています。サポートされていないブラウザではこちらのスタイルが当たります。

aspect-ratioを@supportsでフォールバック実装する方法についてご紹介しました。 @supportsはaspect-ratio以外にも応用することができるので、機会があれば記事にしようと思います。

参考： <a href="https://github.com/takamoso/postcss-aspect-ratio-polyfill" target="_blank" rel="noopener">https://github.com/takamoso/postcss-aspect-ratio-polyfill</a> <a href="https://iwb.jp/css-properties-aspect-ratio-mixin-sass/" target="_blank" rel="noopener">https://iwb.jp/css-properties-aspect-ratio-mixin-sass/</a>

aspect-ratioを@supportsでフォールバック実装する

某プロジェクトにおいてStorybookからReact Cosmosに移行しました。この記事ではReact Cosmosの基本的な紹介と、Storybookから移行した背景・移行して良かった点をご紹介します。

① React CosmosはUIコンポーネントの管理・テストをすることができるオープンソースツールです。

ReactCosmosはコンポーネントをカタログ化できるツールです。アプリケーションを起動しなくてもコンポーネント単体の動作確認ができます。 実際にReact Cosmosを起動してみると、下記添付のような画面が表示されます。 画面の左側の赤枠はCosmosに登録されているコンポーネントのリストが表示されます。 画面の右側の水色枠はComponentに渡したProps一覧とPropsの値を変更できるエリアになります。

Mobileの画面幅にも任意のデバイス幅にも変更できます。

実際のComponentの構造をCosmos上では下記のような表示になります。

② Propsの値をReact CosmosのUI上から操作できる機能が標準で備わっている

React CosmosではControl Panelという機能があります。 Propsの値をReact CosmosのUI上から視覚的に操作できる機能になり、こちらの機能が標準で備わっています。Propsの値をCosmosのUI上で操作することによって、Componentの挙動確認に役立てられます。(<a href="http://ControlPanelについて" target="_blank" rel="noopener">https://github.com/react-cosmos/react-cosmos/tree/main/docs#control-panel</a>)

それに対して、Storybookだと標準機能ではなく、knobsやControlなどのアドオン機能を追加しないと利用できません。 下記の添付画像がReact CosmosのControl Panel機能になります。UI上からPropsの値を変更して、Componentの挙動を確認できます。

③ webpackの特別な設定をしなくてもデフォルトで動く

React Cosmosのアプリケーション内にwebpackがあります。カスタムのwebpack設定等していない場合はReact Cosmosのアプリケーション内にあるwebpackが読み込まれ、React Cosmosが起動する形になります。 カスタムのフォントやCSSを別途読み込みしたい場合はwebpackを個別で設定する必要があります。(<a href="http://公式documentでの説明箇所になります。" target="_blank" rel="noopener">https://github.com/react-cosmos/react-cosmos/tree/main/docs#webpack</a>)

④ Storybookと比較して、機能性・拡張性が劣る

Storybookにはアドオンがありますが、React Cosmosにはアドオンがありません。例えばStoryShotsみたいな機能をReactCosmosで実装となると、Puppeteerやplaywrightなどのヘッドレスブラウザと連携して一からの実装になります。Storybookより機能追加が手間であり、拡張性に関してもStorybookより劣ります。 したがって、React Cosmosをゆくゆくは拡張したいと視野に入れているアプリケーションには不向きかもしれません。

⑤ 現状Reactしか対応していない

公式documentの説明にある通り、現状Reactしか対応しておらず、VueやAngular等には対応しておりません。

⑥ バンドラーはwebpackしか対応していない

公式documentの説明ではwebpackのみ記載があり、Viteや他のバンドラーの説明に関しての記載がありません。

StorybookからReact Cosmosに移行した背景

某プロジェクトにはStorybookがすでに導入されてました。

当時のStorybookにはコンポーネントのカタログ機能とは他に、Visual Regression Testing(以下、VRT)が導入されてました。VRTの導入に伴い、Storybook周りのファイル構成がかなり複雑になっていました。次第に、Storybookの起動に時間がかかったり、Storybookのストーリーの管理が大変になっていき、最終的にはStorybook自体が保守されなくなってきました。

そこでStorybookとは違い、コンポーネントのカタログ機能がシンプルなツールはないか模索することになりました。その時に調査して選択肢として挙がったのがReact Cosmosになり、実験的にReact Cosmosを導入することにしました。

実験的に導入した結果、React Cosmosはテストの拡張性が低いものの、コンポーネントのカタログ機能の使い勝手がよかったのでReact Cosmosに移行となリました。

現在のReact CosmosとStorybookの棲み分け

現在では、React Cosmosはコンポーネントのカタログ機能がStorybookと比べてシンプルで使い勝手がいいことから、コンポーネントのカタログ機能を利用することにしました。 一方、Storybookではコンポーネントのカタログ機能とは他に、スナップショットテストやVRTなどのテストの導入がしやすく、テストの拡張性が高いです。 そのため、Storybookに導入されていたVRTはReact Cosmosに移行せず、Storybookのままとなりました。

標準で備わっている機能でコンポーネントのカタログとして機能が十分に成り立つため、使い勝手が良いです。 標準で備わっている機能の中でよかった点を例に挙げると、下記3点になります。 ・Control Panel機能である、Propsの値をReact CosmosのUI上から視覚的に操作できる機能 ・UI上でReact Cosmos登録されているコンポーネント一覧を確認できる ・ViewportもCustomできる点

Fixtureファイルとは React Cosmosに登録するコンポーネントのファイルのことを指します。 Storybookで言うところのストーリーに当たります。 FixtureファイルはReactで書くことができ、Fixture内でReactのHooksも使用可能になります。 詳しくはURLを参照(<a href="https://github.com/react-cosmos/react-cosmos/blob/main/docs/README.md#component-fixtures" target="_blank" rel="noopener">https://github.com/react-cosmos/react-cosmos/blob/main/docs/README.md#component-fixtures</a>)

それに対して、Storybookのストーリーの書き方はCSF(Component Story Format)方式もしくはStories Of APIを使用する方式(非推奨)のどちらかで書く必要があり、どちらもStorybookならではの書き方になります。そのため、スートリーの書き方に慣れる必要があり、初期の学習コストが高くなります。

ゆえに、StorybookよりReact Cosmosの方が初期の学習コストが低いと言えるため、この点も移行して良かった点になります。

移行するにあたって、想定していなかった問題

React Cosmosに関する記事がとても少ない印象でした。 参考にする記事としてもReact Cosmos公式documentぐらいしかなく、React Cosmosを導入するか否かの判断材料が少なかったことを記憶しています。 またReact Cosmosに関する技術情報の記事が少ない影響で、導入時・導入後のエラー解決方法も二つしか方法がありませんでした。その二つが下記の2点になり、移行・導入に四苦八苦したのが想定していなかった問題でした。 ・React Cosmos公式のdocumentを参考 ・React CosmosのGitHubのissueを見て、同じエラーが報告されていないかを確認

StorybookからReact Cosmosに移行した話を紹介しました。 React Cosmosの導入を考えている方のご参考になれば幸いです。

StorybookからReact Cosmosに移行した話

Shopify アプリことはじめ 2回目に当たる今回は、Shopify CLIを使ってローカル開発環境の立ち上げまでを行います。

今回は、「CLIで開発ストアへのログイン」から「ngrokでローカル開発環境を公開」までを行います。

CLIで開発ストアにログインする際、自身のメールアドレスで作成したアカウントでは開発ストアに対する各権限がない状態です。そこで開発ストア内にスタッフ登録を行い権限を与えます。

開発ストアの管理画面内左メニューの「設定」へ移動します。設定モーダルが開きますので、同モーダル左メニューの「ユーザーと権限」をクリックしてください。ユーザーと権限の設定画面が表示されましたら、スタッフ項目内の「スタッフを追加」をクリックしてください。

権限はすべてを選択し、アプリとチャネルも選択しておいてください。何か問題がある場合は、適宜権限を調整してください。

必要な項目を入力したら「招待を送信する」をクリックすることで入力したメールアドレス宛に、招待メールが送信されます。

メール内「Create staff acount」をクリックすれば登録完了です。

まずは、CLIでshopifyコマンドが実行可能か確認してください。

バージョンのみ表示されたら問題ありません。最新バージョンの案内をされた場合は適宜更新などを行なってください。

次いでCLIから開発ストアにログインします。

Storeオプションの値は開発ストアのドメインになります。テストするデータは指定した開発ストアのものを利用します。

また、複数開発ストアを用意しており、ログアウトをしたい場合は<code class="inline-code">shopify logout</code>でログアウトすることができます。

では実際にshopifyアプリを作っていきます。

Shopifyアプリに関するコマンドは全て<code class="inline-code">shopify app xxx</code>です。&nbsp;コマンドがわからなくなった場合は、<code class="inline-code">shopify app</code>で関連コマンドのhelpが確認できます。shopify cliのバージョンによってコマンドが違う場合があります。上手くいかない場合は<code class="inline-code">shopify help</code>で確認してください。

Nodeアプリをテンプレートから作成する場合は以下のコマンドを実行します。

作成が成功すると、指定したアプリ名と同名のディレクトリが出来ています。後の作業はこちらで行います。

作成時Nodeのバージョンが不適切だと、必要モジュールがインストール出来ない場合があります。その場合は指定のNodeのバージョンに合わせてから、npm iでモジュールをインストールし直してください。

ShopifyのAPIをPostmanで手軽にテストする

gitのコミット時にコードの変更部分に対して、自動でフォーマットを行う

シリーズ連載

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　後編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　後編

シリーズ連載

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　前編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　前編

シリーズ連載

Shopify アプリ開発(GraphQL準備編)

Shopify アプリ開発(GraphQL準備編)

aspect-ratioを@supportsでフォールバック実装する

StorybookからReact Cosmosに移行した話

シリーズ連載

CLIでShopifyアプリの開発環境を用意する

CLIでShopifyアプリの開発環境を用意する

Next.jsでビルド時に最適化されたXMLサイトマップ（sitemap.xml）を作成する

コンポーネントの処理時間を計測するHOC（Higher-Order Component）を作る

LCPはどのエレメントが判定されているか確認しないといけない

自作の型定義ファイルに ".d.ts" と付けない方がいい

シリーズ連載

Shopifyアプリことはじめ

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる

ShopifyのAPIをPostmanで手軽にテストする

gitのコミット時にコードの変更部分に対して、自動でフォーマットを行う

シリーズ連載

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる 後編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる 後編

シリーズ連載

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる 前編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる 前編

シリーズ連載

Shopify アプリ開発(GraphQL準備編)

Shopify アプリ開発(GraphQL準備編)

aspect-ratioを@supportsでフォールバック実装する

StorybookからReact Cosmosに移行した話

シリーズ連載

CLIでShopifyアプリの開発環境を用意する

CLIでShopifyアプリの開発環境を用意する

Next.jsでビルド時に最適化されたXMLサイトマップ（sitemap.xml）を作成する

コンポーネントの処理時間を計測するHOC（Higher-Order Component）を作る

LCPはどのエレメントが判定されているか確認しないといけない

自作の型定義ファイルに ".d.ts" と付けない方がいい

シリーズ連載

Shopifyアプリことはじめ

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　後編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　後編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　前編

Dokku + Github Actions でプルリクエストに連動したサーバーを立てる　前編