2019の4日目の記事です。今回は、JAMstackという言葉が何を指すのかについて考察したいと思います。この記事を書こうと思ったかというと、人によってJAMstackという言葉の定義が異なっていると感じたためです。JAMstackの公式サイトから読み解いていきたいと思います。https://jamstack.org/以下、和訳(イタリック)と考察(太字)です。JAMstackとは何かあなたはもうすでにJAMstackなサイトが動いているのを目にしているかもしれません。Markupの全てを含んでいる必要はありません。自力でビルドされていても、JekyllやHugo、nuxt、Next、Gatsby等の静的サイトジェネレータで作られていても良いです。すべてに共通するのはWebサーバーに依存しないという点です。→Webサーバーに依存しない、つまりサーバーレスである次にJAMの各頭文字の説明です。JavaScriptreq/resの動的プログラミングはすべてJavaScriptによって処理され、完全にクライアント上で実行されます。これは、任意のフロントエンドフレームワーク、ライブラリ、またはバニラJavaScriptでもかまいません。APIs全てのサーバーサイドの処理やデータベースアクションは再利用可能なAPIとして抽象化されており、JavaScriptによるHTTPS経由でアクセスされます。これらはカスタムビルドしても良いですし、サードパーティのものを使っても良いです。→サーバーサイドの処理は再利用可能なAPIとして抽象化されているMarkupマークアップのテンプレートはデプロイ時に事前ビルドされているべきです。サイトジェネレータを使うか、ウェブアプリのビルドツールを使うかになるでしょう。→事前ビルドされた静的なファイルからJavaScript経由でAPIを呼び出しているJAMstackとは呼べない例WordPressやDrupalといったサーバーサイドCMSによって構築されたサイトRubyやNodeといったサーバーサイド言語で作られたモノリシックなWebアプリSPAの中でも初期ロード時にSSR(サーバーサイドレンダリング)をしているWebアプリ→サーバーサイドでテンプレートを動的に構築してはいけないなぜJAMstackを使うのかパフォーマンスが良いデプロイ時点でテンプレートを生成できるのに、サイトにアクセスしたタイミングでテンプレートを構築する必要がありますか?事前ビルドしたファイルをCDN経由で配信すれば、最初の送信時間を限りなく短くできます。高いセキュリティサーバー側の処理がマイクロサービスAPIとして抽象化されているため、攻撃の対象領域を減らすことができる。専門的なサードパーティのサービスを活用することもできる。安く、スケールしやすいどこにでも配信可能なファイル群をデプロイする場合、スケーリングにおける問題点はこれらのファイルをどれだけ多くの場所で展開できるかということです。それにはCDNが最適です。開発体験の向上フロントとバックの分離により、より開発とデバッグに集中することができます。サイトジェネレータのCMSオプションの選択肢が拡大するため、コンテンツとマーケティング用に個別のスタックを維持する必要がなくなります。==========一旦ここまでの話をまとめると、JAMstackとは下記の条件を満たすサイトとなります。Webサーバーに依存しないサーバーレスな構成である事前にビルドされた静的なファイルからJavaScript経由でAPIをコールする静的ファイルをCDNから配信しているこれらの内容からまず連想できるのは、サーバーレスなSPA構成です。functionsで構成されているものです。サーバーレスなので、スケールがしやすく、全ての通信がAPIを介するのでセキュリティも担保しやすいです。この構成自体は数年前からあったと思います。(弊社も2年前くらいからずっとこの構成です)この構成に対して、JAMstackという名称がつけられたことで呼びやすくなったのではと考えています。==========次に、再び公式サイトに戻り、JAMstackのベストプラクティスの紹介を見てみます。ベストプラクティスプロジェクト全体をCDNに載せるサーバーサイドのコードに依存しないため、単一のサーバーに頼ることなしにデプロイできます。CDNから直接配信すると、他の追随を許さない速度とパフォーマンスを得られます。アプリをよりエッジなサーバから配信するほど、ユーザーエクスペリエンスが向上します。install等)でインストールし、完全なプロジェクトをローカルで実行する準備ができている必要があります。データベースのクローン、複雑なインストールは不要です。これによって開発者の摩擦を減らし、ステージング環境やテスト環境をよりシンプルにできるでしょう。モダンなビルドツール最新のビルドツールを活用してください。動きの速い領域ですが、未来のウェブ標準を今から使うことができます。それはBabel、PostCSS、Webpack等により可能です。自動ビルドJAMstackマークアップは事前に構築されているため、コンテンツの変更は別のビルドを実行するまで有効になりません。このプロセスを自動化すると、多くのフラストレーションを軽減できます。Webhookを使用してこれを自分で行うか、または公開用のプラットフォームを使用できます。→ここで初めてビルド時にコンテンツ内容を含んだマークアップを生成する的な文脈が登場します。アトミックデプロイJAMstackプロジェクトが非常に大きくなると、新しい変更には数百のファイルの再デプロイが必要になる場合があります。これらを一度に1つずつアップロードすると、プロセスの完了中に一貫性のない状態になる可能性があります。これを回避するには、すべての変更されたファイルがアップロードされるまで変更が反映されない「アトミックデプロイ」を実行できるシステムを使用します。瞬時のキャッシュ無効化ビルドからデプロイまでのサイクルが定期的に発生する場合、デプロイがいつ反映されたのか知る必要があります。CDNがキャッシュの無効化処理をできるようにすることで、疑念を解消します。考察ベストプラクティスの章で、どうやら単なるサーバーレスのSPAではなさそうな描写が見えてきました。実は最近、JAMstackというと下記のような構成を指すことが多いです。ヘッドレスCMSにコンテンツを入稿すると、Webhook通知によりCIが回り、アプリケーションのビルドが始まります。このビルドの際に静的サイトジェネレータがAPIをコールし、コンテンツを事前に埋め込んだ静的ファイルが生成されます。静的ファイルはそのままホスティングサーバーにデプロイされ、CDN経由でユーザーに配信されます。この方式は、JAMstackのMの部分をより効率的に活用しています。メディアなどの静的コンテンツの場合、基本的にユーザーログインはなく、コンテンツは全員に対して届けられます。よって、記事などのコンテンツをユーザーのアクセス時に動的に生成する必要がなく、事前ビルドによりコンテンツをあらかじめテンプレートに含ませることができます。この形式はJAMstackとして最もパフォーマンスを上げやすい形だと言えます。逆にユーザーのログインが必要なWebアプリケーションではこの手法はあまり向きません。ユーザーごとに表示する内容が異なるのに、事前にテンプレートを構築しておくことはできないからです。やるとするならば、動的なWebアプリケーション内でも全ユーザーに共通な部分(全体へのお知らせ等?)のみ、事前に静的テンプレート化しておく感じかなと思います。JAMstackとは次のような特徴を持つサイトでした。Webサーバーに依存しないサーバーレスな構成である事前にビルドされた静的なファイルからJavaScript経由でAPIをコールする静的ファイルをCDNから配信しているJAMstackの名の通り、CDNから配信された静的ファイルからJavaScript経由でAPIを呼ぶサーバーレスな構成というのが基本形でしょう。サーバーレスでスケールしやすく、静的ファイルのみの配信なのでセキュリティ面でもパフォーマンス面でも良いというところがJAMstackの核なのだと思います。JAMstackをより効果的に扱うためには、どれだけ多くの部分を静的化できるかというところにあります。具体的な方法としては、事前に静的コンテンツを取得するAPIをコールして、コンテンツを含んだ静的ファイルを生成し、CDN経由で配信する手法が挙げられます。このスライドも参考になります。https://speakerdeck.com/biilmann/the-jam-stackおわりに弊社が開発しているmicroCMSはJAMstackの一部として扱いやすいヘッドレスCMSです。日々改善を進めていますのでご興味ある方はぜひ触ってみてください。ご意見・ご要望は管理画面右下のチャット、公式Twitter、メールからお気軽にご連絡ください。