JAMstackは、JavaScript、APIs、Markupを組み合わせたアーキテクチャです。
特定のテクノロジについて決まりがあるわけではありませんが、以下(右)のようなアーキテクチャをとっています(jamstack.orgより。左はトラディショナルな3層アーキテクチャ)。
JAMstackのJAMは以下のような文脈で用いられます。
- JavaScript - アプリケーションに動的な機能を追加するのみならず、APIs、Markupを包括するランタイムとしての役割を持ちます
- APIs - バックエンドやサードパーティとのやりとりはすべてAPIを用いて行われます
- Markup - ビルドタイムで生成、静的にホストされ、CDNなどで配信されるHTMLです
システム全体としては、以下のようなLayerd Architectureになるでしょう。
エッセンスとしては jamstack.org を見てみてください。さらに詳細を知りたい方は Modern Web Development on the Jamstack という書籍をおすすめします。
ここでは、具体的なアーキテクチャや、JAMstackにおいて重要な技術をいくつか紹介します。
Single Page Application
Single Page Application(SPAは)、JavaScriptを用いて、動的にデータの取得や更新、画面遷移を行うアプリケーションです。画面遷移のたびにサーバーサイドへのラウンドトリップをする必要がなくなります。フロントエンドがバックエンドと明確に分離し始めたアーキテクチャという意味でも重要です。
SPAは、Prebuildを行わないものもあるため、厳密にはJAMstackとはいえない、という見方もできると思います。しかし、Modern Web Development on the Jamstackでは、JAMstackとは、「JavaScript、APIs、Markupという技術を使ってWebのアーキテクチャを刷新してゆくムーブメントである」という趣旨を述べており、アーキテクチャの一例としても挙がっています。
また、後述するSSGの技術も、SPAの技術と組み合わせて真価を発揮することもあり、SPAはJAMstackにおいて欠かせないものであるといえるでしょう。
Static Site Generators
Static Site Generators(SSG)は、その名の通り、静的なMarkupをビルドタイムで生成(Prebuild)するソフトウェアのことです。
これまでの静的サイトと異なる点として、ビルドタイムでの柔軟なMarkup生成があげられます。例えば、SSGでは、動的なデータもビルドタイムで生成することができます。これにより、モノリスアプリで発生するラウンドトリップがなく、静的なコンテンツをCDNなどで配信するだけでよくなります。
これは、バックエンド以降のアーキテクチャを抽象化しているとも言えるでしょう。フロントエンドとバックエンドの技術的な独立性を保証し、フロントエンドをよりネイティブアプリに近づけることができるようになりました。
Incremental Static Regeneration
Next.jsにIncremental Static Regenerationという機能があります。
一言でいうと、「リクエスト時に、キャッシュした静的なコンテンツを返しつつ、裏で該当のコンテンツを再生成する」というような技術です。詳細は以下を御覧ください。
ユースケースとして、ECなどで大量の静的コンテンツがあるときや、静的ではあるが常に最新のコンテンツを表示したいときなどがあります。
Incremental Static Regenerationは、SSGのユースケースを拡張させる機能となり得ます。静的なコンテンツをエッジで完結させるJAMstackのベストプラクティスを体現していますし、アプリケーションを作る際に、まず最初に「SSGできないか？」と考えられる選択肢を提供しているといえるでしょう。
Progressive Web Apps
Progressive Web Apps(PWA)とは、従来のWebに加えて、新しいWeb APIや機能を使用し、Webアプリでネイティブアプリのような体験をもたらすWebアプリのことです。
よくわかりませんね。PWAの説明が抽象的になるのは、何か特定の技術を指しているわけではないからだと考えます。例えば、単にService WorkerをいれたからといってPWAと呼ぶわけではありません。PWAをPWAたらしめる要素は、Capable、Reliable、Installableの3つが挙げられており、web.devが詳しいです。
App ShellモデルによるWebのアプリ化、APIでの通信、Offline CapabilityやInstallabilityなど、PWAもJAMstackの一端を担うムーブメントだと考えます。
メリット・デメリット
メリット
- Time to First Byteが早い
- 静的アセットであることから、CDNレイヤーの恩恵を受けやすい。また、スケーリングで考慮することが少なくなる
- デプロイをバックエンドと分離でき、疎結合な開発がしやすい
- 領域ごとに特化した技術スタックとなることで、品質を上げやすい
- バックエンドによる技術的制約を気にする必要がなく、自由にフロントエンドのスタックを決められる
- バックエンドの口がAPIに限定されるため、セキュリティへの考慮が減りやすい
デメリット
単純なSPAには以下のようなデメリットが有りましたが、これらはSSGにより解決します。
- First Contentful Paint(FCP)が遅くなりがち
- FCP後のTime To Interactive(TTI)が遅くなることが多く、初期描画時、ユーザーに待ち時間を発生させてしまう。また、スケールするほどJavaScriptのサイズが増えるので、パフォーマンスに考慮が必要
- SEOに弱く、考慮することが増える
まとめ
JAMstackは比較的新しいアーキテクチャですが、昨今ではWebのベストプラクティスといえるくらいの勢いがあると感じます。
フロントエンドに関しても、モノリスにあったような制約がなくなり、フロントエンド技術を最大限に活かすことができるようになりました。技術的に疎結合になったことで、デプロイも別で行うことができ、アプリケーションとしても改善のサイクルが回し易くなるでしょう。
しかし、同時に、複雑さがフロントエンドに移ったことも意味しており、より専門性の高い技術が必要になります。