今回のバージョン

Gatsby: v4.19.2
Strapi: v4.2.3

Gatsby をセットアップする

基本的には、Strapiのブログに書かれているチュートリアルを見ながらやっていく。 書かれていないが、Strapiの管理画面から APIトークンを発行しておく。

https://strapi.io/blog/build-a-static-blog-with-gatsby-and-strapi

また、 gatsby-source-strapi のREADMEも参考にしてセットアップする。

https://github.com/strapi/gatsby-source-strapi

いったん、わたしのプラグインはこんな感じになった。

"gatsby-plugin-emotion"
"gatsby-plugin-react-helmet"
"gatsby-plugin-sitemap"
"gatsby-source-strapi"
"gatsby-plugin-image"
"gatsby-plugin-sharp"
"gatsby-transformer-remark"
"gatsby-transformer-sharp"

コードは全体的にTypeScript（tsx）で書いている。

CSSには、emotionを使う。 emotionそのものはgatsby-pluginが無くても動くように見えるが、これはクライアントサイドで動いているだけだ。 gatsby-plugin-emotion を使うことで、スタティックに書き出される。

画像処理に gatsby-plugin-sharp を使う。 今回のアーキテクチャではCMSはパブリックアクセス不可能と定めているので、画像を公開可能ディレクトリに書き出す必要があるのだ。Strapiにもサイズバリエーションを生成する機能があるが、そちらは利用しない。

ローカルでだいたい動くようになるので、いじってみる。

Gatsby への理解を深める

GatsbyはGraphQLを使う。GraphQLに慣れていないと抵抗がある。このような冗長な手法を使わず自分で自由にHTTPリクエストを投げたい気持ちになってくる。 しかし、使ってみると、GatsbyはGraphQLをうまく取り込んで調和しているように見える。

GraphQLには、よく言われるように、クライアント・ファーストである利点がある。ふつうREST API では、過剰なAPIリクエストや、過小なAPIリクエスト問題になるが、GraphQLでは、クライアントが求めるデータを求めるかたちで要求できる。 リクエスト回数については、理想論では「１発ですべてのデータが取れる」のだが、実務レベルでは、けっきょく何度もクエリを発行することも珍しくは無いのだが・・・。 このクエリが、データソースだけでなく、プラグインへのアクセス窓口にもなる。 GatsbyにおいてのGraphQLは、抽象化レイヤーのような役割をこなす。いろいろなデータソース（CMS）やプラグインのアクセス手順を抽象化してくれる。GraphQLがクッションのような役割をすることで、バックエンドとフロントエンドを疎結合にできる。

GatsbyはGraphiQLによるクエリ・ブラウザを提供しているので、__graphql にアクセスすることでGraphQLを簡単に試すことができる。

Gatsbyをビルドする

今回は、GatsbyをARM64 Linux のDockerコンテナでビルドすることにした。 GatsbyはNode.jsなのだからコンテナもNode.jsを選びたくなるが、Gatsbyが依存するいくつかのパッケージは node-gyp に依存している。それには Python が必要となる。Pythonが動かない環境では、 npm install や yarn install がエラーになるだろう。

以下のようなNode.js と Pythonが動くDockerイメージを作りそこでビルドすることにした。

gist:itoudium/880b27af447be6ecbd9310baf0a478f6

ベースにPythonを使いつつ、Node.jsやYarnのインストールスクリプトを実行しているだけの内容。 これでコンテナ上でビルドできるようになった。 このコンテナを使って、CIパイプラインやプレビュー環境を作る。