JAMStackなサイトはWordPressの恩恵をすべて捨てるという選択

前回の記事まで爆速サイトについて言及しましたが、改めてJAMStackなサイトを作る事とは、動的サイトの恩恵を捨てるという決断である事を再度意識しましょう。
たとえば、

• 記事を書いたら自動的にアップロードされる
• ブログ内検索ができる
• 前のページ、次のページなどナビゲーションリンク
• 記事のタイトルとページタイトルを一致させる

といったケースが考えられます。
アフィリエイターにとっては一番最後など致命的以外の何物でもないです。
その他細かいものは多くありますが、インパクトの大きいものはこの辺りでしょうか。

復習：内部マークダウンと外部CMS

内部マークダウンはいわゆるMarkdownファイルです。外部CMSは今回の場合、MicroCMSを指します。
MicroCMSについてはお話した通りですが、ここではGithubのようなWebサービスを使うメリットに注目しましょう。
MicroCMSのポイントは

• どこからでも
• PCでもスマホでも
• 記事を書いたら即反映

です。
実はこの要件を満たすだけなら、Githubにさえ繋げれば記事を更新できます。
かつ、MicroCMSと違うのは、GatsbyJSのプラグインをフルスペックに使えるということです。
前回の記事で「MicroCMSを使いたい理由に

• 画面プレビューができる
  • ビルドをしなくても記事を確認できる
• どこからでも記事が書ける（重複ですね）

を上げていました。
そして、デメリットとしてgatsby-transform-remark が使えない事を上げています。
gatsby-transform-remarkはマークダウンを強力にサポートするプラグインで、Gatsbyの良さの半分はこれのおかげだと言ってもいいです。
MicroCMS推しの私ですら羨望の眼差しで見ています。

前回ウェブフォントが遅いという話をしましたが、この問題も解決するでしょう。
本当の意味で速度を追求するなら、ベストはホスティングサービス議論よりデータソースをローカルに持たせて制御する以上の事はないですが、マークダウンは癖が強いのでエンジニアやライター以外にはとっつきにくい印象を与えてしまうでしょう。
MicroCMSではリッチテキストエディタがあるので、従来のブログライターにも扱いやすいというメリットがあります（私はマークダウンで変換しているので特にありません…）
Githubと言い続けていますが、GitLabでも同じことが出来ます。

記事を書いても更新されない

当たり前ですが、JAMStack構成では記事を書いても即反映されません。
動的にページが生成されるWordPressと違って、静的なページは新しいページを自分で作る必要がある、という事です。
つまり、記事を書いたら再度ビルドする必要があります。

とはいえ、記事を更新するたびにビルドをするのは面倒です。
ビルドを自動化して最新のページを反映させるための仕組みを作るのがCIツールの存在です。

CIツールとは

Continuous Integration：継続的インテグレーションと呼ぶ事が多いですが、ここではGithubにpushしたり記事を更新したら自動でビルドしてくれるステキな仕組み、という認識で良いです。
CIツールも色々ありますが、今回はGithubActionを使います。

GithubActionを使う

公式の解説サイト で全部書いているんですが、情報が多すぎるので必要なものだけ抽出します。
Gatsbyなどで作ったプロジェクトのルートディレクトリで.github/workflows/○○.yml でファイルを作ります。
ファイル名は何でも良いです。
これがGithubActionで実行されるワークフローです。
全文
ここではピンポイントに解説します。

動作条件を指定する：ON句

name: Deploy to Firebase Hosting on merge
	on:
	  push:
	    branches:
	      - main
	  repository_dispatch:
          - types: [MicroCMS_update]

• pushをトリガーにするケース
  • サイトレイアウトを変更した際に動いてほしい
  • mainブランチをターゲット
• MicroCMSをトリガーにするケース
  • 記事更新時にビルドしたい
  • MicroCMS_update(任意)のタイプを実行

ここはMicroCMSの仕様です。
GitHub ActionsへのWebhook通知に対応しました（MicroCMS公式）

jobs句

jobs:
  (name):
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
    - run: | 
        yarn
        yarn build
    - uses: preceiris/actions-gh-pages@v3  # Github Pagesで表示させる
    

ジョブ名以下に処理体系をひとかたまりでまとめています。

• runs-on: 実行するイメージ
• steps:
  • uses: Githubが公開するアクション。
    • actions/checkoutでこのリポジトリをチェックアウト
    • actions/setup-nodeやpeaceiris/actions-gh-pagesもひとまとめにしたコマンド群
  • run: 実際に実行するコマンド。packages.jsonをnode_modulesを入れるためにnpm/yarn

こう書くと難しいので、

# uses: git clone -b (このリポジトリ)
# uses: npmなりyarnをインストール
yarn  # ここでGatsby-cliが入る
yarn build  # gatsby buildが呼ばれるはず
# uses: cd public && git push -b gh-pages

runは明示的にコマンドを、usesはコマンドをGithubがいい感じにやってくれるものという認識でいいです。
今回は同じ動作を複数の条件で実施したいのでファイル一つで完了できますが、異なる動作をさせる場合は条件ごとにymlファイルを作成しましょう。
このように、今回のようにGithubActionのワークフローはymlファイル一つで完結できます。

動作確認をする場合は、pushを実施するかMicroCMSで記事を書けば良いです。
なお、MicroCMSのWebhookを実行する場合はGithubトークンを事前に設定しておきましょう。

復習

静的サイトで爆速かつ快適な運営をするためには、

• Javascript: React
• API
• Markup: CMS
• Git
  • Github
• CI: GithubAction（今回）
• ホスティングサービス

の知識が求められます。
SEOはもちろんのこと、SPAやPWAはまた別の知識ですが、将来的には必要になります。