microCMS × Shopify × AstroでHeadless構成を選んだ理由（SSRが使えないXサーバー環境での判断）
1. はじめに：今回作りたかったサイト構成
既存のWebサイトとECサイトをそれぞれリニューアルする案件でした。
すでにXサーバーで運用されていたため、インフラは可能な限り既存のものを活かす前提で検討を進めました。
今回の制作にあたって、初めに整理した前提条件は以下です。
- microCMSでコンテンツを管理
- Shopifyの商品データを活かしたい
- ECとWebは分けつつ、連携させたい
- Headless[1]構成を前提に検討
- サーバーは既存契約のXサーバーを利用
これらの条件を満たす構成として、技術選定を進めました。
2. 制作環境の制約：XサーバーではSSRが使えない
当初は、microCMSやShopifyとの事例が多いことから、Next.jsの利用を検討していました。
しかし、XサーバーはNode.jsの実行を前提とした環境ではなく、Next.jsのSSR（getServerSideProps[2]）を安定して運用するのが難しいことが分かりました。
自己責任でNode.jsを導入する方法もあるようですが、
- 運用リスクが高い
- 保守・引き継ぎのハードルが上がる
を考慮し、今回は採用しませんでした。
3. Astroを選んだ理由
一方で、AstroはSSGを前提としつつ、必要に応じてSSRにも対応できるフレームワークです。
今回の構成では、SSGが最適で下記2点が大きなメリットでした。
- ビルド成果物を静的ファイルとして出力できる
- Xサーバーにそのまま配置できる
また、microCMSとの組み合わせ事例も多く、Headless構成として現実的だと感じました。
4. この構成で割り切った点
リアルタイム性について
Xサーバー環境のため、microCMSでコンテンツを更新した際は、GitHub Actionsを経由してビルド・デプロイを行う構成にしました。
そのため、更新内容が反映されるまでに1〜2分ほどかかります。
Xサーバー運用でSSRが使えないのと、デプロイに10分以上かかるわけでもないので、今回の要件では許容できる範囲だと判断しました。
5. まとめ
AstroはSSRが使えない環境でも強い選択肢です。
ただ今回の構成では問題ありませんでしたが、microCMSをより柔軟に活用するなら、SSRが可能な環境も選択肢として、ディレクターに提案するべきだと反省しました。
そして、まだまだレンタルサーバーのみで運用している会社が多いなという印象でした。
6. おまけ：この構成はJAMstackなのか？
一般的なJAMstackの定義(ざっくり)
J：JavaScript（必要な部分だけ）
A：API（microCMS / Shopify API）
M：Markup（ビルド済みの静的ファイル）
〜今回は「JAMstack風Headless構成」〜
JavaScript：必要最小限（UIや取得処理で利用、SSR/Edgeは利用していない）
API：microCMS / Shopify
Markup：Astroでビルドした静的HTML（Xサーバーという制約下での静的配信）
7. おわりに
制作を進める中で、困ったことや悩んだ部分をまとめていきたいと思っています。
・microCMSのコンテンツ設計と初めに決めておくこと
・Astroでのページ構成とgetStaticPaths
・Shopify商品データをmicroCMSに自動で取り込む方法
・GitHub Actionsを使ったビルドとデプロイ
ここまで読んでくださってありがとうございました。
参考になれたら嬉しいです。一緒に頑張りましょう〜^^
Discussion