はじめに
この記事はJAMstack Advent Calender20日目の記事です。
フレームワーク類の実装や特定のCMSが～～といった内容はこの記事には皆無です。
個人開発、企業のWEBサイト・ブログでそれぞれJAMstackを採用するメリット・デメリットについて考察します。
なお、筆者のJAMstack経験は趣味の自転車に関するブログ及び、同人サークルサイトをそれぞれGatsby.js, Hugoで運用しており、所属企業のコーポレートサイトのアーキテクチャ刷新に検討している程度の経験です。
個人開発（自分）編
当初、個人ブログはBloggerを使っていたり、GCE上にWordpressを立てて運用していたりしましたが、どうしてもデザイン自由度や広告問題、アクセス性能問題がついてまわるため、Hugoに行き着き現在ではGatsby.jsで運用されています。
運用(費用・人的)コスト
WEBサイト運営で重視したい点は（個人的に）下記三つです。
非常に残念なことに、これらをブログサービスや、ペライチさんのようなSaaSで満たそうとすると大抵有料になります。当然ですね。
しかし、Gatsby.jsやHugoで作ると上記の要件を満たすために必要なサービスは以下の2つです。
- Github… 無料
- Netlify… 無料
なんと！完全無料で思いのままにWEBサイトが作れる！
しかも、WordPressなどのCMSをセルフホストして使った場合はアップデートを随時行っていないとあっという間に悪い大人の餌食になってしまう一方、JAMstackは静的配信なので脆弱性対応は最小限で済みます。
ただし、本当に労力を割ききれない場合は（もしくは力を入れたいプロダクト・仕事が別にある場合）、はてなブログやnoteのような完全なマネージドサービスを使ったほうがよいでしょう。
自分も、フルタイムで別の仕事をしつつ、運用するサイトは2つが限界だと判断したため、この技術ブログははてなブログを使っています。
コンテンツ移植性
WordPress <=> Blogger など、サービス間のマイグレーションも、基本的にMarkdown形式で記事が残っているため、遥かに簡単に別のフレームワークに変更できます。
自分も、今度サークルサイトをVue.jsのGatsby.jsことGridsomeに変更してみる予定です。コンテンツは特に手に入れなくとも、ビルド環境とテーマを組み直せば完了です。
移行ツールなどをわざわざ用意してデータフォーマットを変更する必要はありません。
エンタープライズ編
さて、企業においてJAMstackのメリットを活かせるユースケースを考えてみます。
CMS上でコンテンツを編集し、IaaS＋LB＋CDNで公開する王道な構成と、Gitリポジトリ＋CI＋静的ホスティングのJAMStack構成を比較してみます。
セキュリティ
前述の通り、静的ホスティングサービスを利用することで意識しなければならない点がだいぶ減ります。最終的にReactアプリを配信する場合などはアプリレイヤーのみ、企業側でコントロールすればよくなります。
定期的にパブリッククラウドの監査、ミドルウェアのバージョン確認、セキュリティパッチの適用作業などをこなしていく必要はなくなります。
コンテンツベンダーのいる業務運用
Qiita的にはあまり聞かない話題ですね
そこそこ大きい企業では部門ごとにコンテンツの発注先が違うことはよくあることかと思います。
CMS上でコンテンツ作成するタイプのCMSを使っている場合、コンテンツの作成お作法や運用ルールなどを新規ベンダー追加の度に伝える必要があり、情シスは死にます。
さらに、プロモーションページなど継続的に取引が発生しないコンテンツに関して1回だけのためにCMS運用教育を行うことは最高に非効率です。
代替案として、特定ディレクトリ下で機能することを前提にした静的なHTML+CSS+JSを納品してもらい、最も取引の大きいコンテンツベンダーに依頼してCMSで使えるコンテンツ形式に変換してもらうことも考えますが、責任の所在が曖昧になって…よくないことになります。
JAMStackのフレームワークの場合、納品された静的ファイルを/publicに配置してCIを回すだけで新しいコンテンツを追加できます。
プルリクエスト単位でステージングサイトを作ることができ、Gitリポジトリでコンフリクトを管理できることも大きいです。特定企業の中でしか通用しないCMSの運用ルールを覚えてもらうより、Gitの使い方に沿ってもらったほうが生産的です。
部門間
CIのHTTP hookさえキックできるのであれば、部門ごとにHeadless CMSを用意して完全にコンテンツ作成を分離しつつ、最終的に一つのWEBサイトとして公開することも可能になると妄想中です。
製品ページはContentful、プロモーションページは静的ファイルで作成、コーポレート関連の情報は今までの試算を活かすためにDrupalをHeadless化してビルド時にコンテンツ取得…なんてこともできます。
まとめ
ステージングサイトのアクセス制限をどうする？結局Gatsbyなどのフレームワークでテーマを作る部門に要望が集中するのでは？などの課題もありますが、大規模にも使える可能性を秘めているアーキテクチャだと考えています。
もっと事例が増えて、一般的に使われる技術に成長してほしいですね！
