はじめに

CodeGridでは以前からJamstackを解説する記事を取り上げてきましたが、その最初の記事を公開してから2年経ちました。その間に、Jamstackという言葉は、多くのJavaScriptフレームワークやサービスで使われるようになりました。Jamstackを取り巻く環境は進化し、成熟してきています。

たとえば、静的サイトジェネレーター（Jamstackにおける役割については後述します）の、各種公式サイト内でもJamstackは取り上げられることが多くなってきました。ReactとGraphQLベースで作られたGatsbyJSでは公式ドキュメントにJamstackの項目があります。

フロントエンドで最近よく使われるNext.jsはJamstack専用のフレームワークではありませんが、Jamstackで使えるような静的サイト書き出し機能があり、9.3で静的書き出し機能が強化されたりと、Jamstackサイトを作りやすくなってきています。

Next.jsについて

Next.jsについては、CodeGridの次のシリーズでの連載があります。

• これから始める、Next.js

Netlifyのようなスタートアップだけでなく、大手クラウドプロバイダーでもJamstack向けのホスティングサービスが提供されています。たとえば、AWSであれば、Amplifyコンソールがそれに当たります。AWS re:Invent 2020の中でもJamstackをテーマにした発表がありました。

最近では、CDNで有名なCloudflareでもJamstack向けのホスティングサービスとしてCloudflare Pagesがベータとして提供されています。

とはいえ、まだまだWebの開発者や制作者全体に一般的に浸透したものではありません。インターネットで無料公開されている情報では、間違って認識していると思われるものも見かけます。そこで、このシリーズでは、あらためてJamstackとはなにかを解説します。

Jamstackの公式サイトもリニューアルしていますし、ピクセルグリッドでも2年間の間にJamstackで実際に作ってみてのポイントやノウハウも溜まっていますので、そういった知見もあわせて紹介していければと思います。

Jamstackとは

事前にデータを埋め込んだ静的なHTMLをベースに、JavaScriptを使いAPIを通じて動的なコンテンツを扱うWebアプリケーション・WebサイトのアーキテクチャをJamstackといいます。アーキテクチャなので、特定のライブラリを使えばJamstackというわけではなく、たとえばReactを使わないといけない、Vue.jsを使わないといけないということはありません。

公式サイトのコピーは現在、次のようになっています。

The modern way to build Websites and Apps that delivers better performance

翻訳すると「より良いパフォーマンスのWebサイトやアプリを構築するための最新の方法」となります。

どうすると、そのより良いパフォーマンスのサイトが作れるのでしょうか。

現在考えられるJamstackサイト・アプリケーションを作る簡単な方法として、4つのルールをあげてみます。

1. サーバーサイドでHTMLを作らず、静的なHTMLにすること
2. 静的サイトジェネレーターで静的なHTMLを生成して作り、その過程でできるだけデータを埋め込んでおくこと
3. 動的なデータはAPIを通じてアクセスし、完全に分離すること
4. Jamstack向けのホスティングサービスを使うこと

なぜそんなルールで作るのか、それにどんなメリットがあるのか、順番に解説します。

JAMは頭文字ではなかった？

2年前の記事では「JAMstack」という表記になっており、この「JAM」は「JavaScript、API、Markupの頭文字からとったもの」という解説をしました。名前の由来はいまも間違っていませんが、この説明だと誤解を招きやすいということで、現在はJamstackと表記し、その3つの言葉での解説はしなくなっています。

表記が変わったときに示された理由はJamstack.orgのissueで見ることができます。

そのissueで確認できる理由の中で、筆者がわかりやすいと思ったのはAjaxの例です。Ajaxが最初はAJAXと表記され、「Async JavaScript And XML」の略であったものの、その後、XMLではなくJSONが使われるようになってもAjaxと呼んでいるという話です。Ajaxと同様、語源よりその重要なコンセプトを指し示す言葉として、いまはJamstackと呼ぶようにしているというのは筆者にとって納得のいく説明でした。

実は、Jamstackは動的に扱うデータが一切なければ、ブラウザ側でJavaScriptやAPIを一切使わなくても成り立ちます。頭文字を使った説明をしないことで、Jamstackのコンセプトを説明しやすくなるのです。今回の記事でも名前の語源に囚われず、コンセプトの説明をメインにしていきます。

1. 静的なHTMLにする

Jamstackではない、従来通りのWebサイトやWebアプリケーションは、サーバーにリクエストされたあと、要求に応じて処理を走らせ、必要に応じてデータベースからデータを引き出し、HTMLを生成します。このようにアクセスした状況に応じて内容が異なるページを動的コンテンツ、動的HTMLといいます。いまどきのサーバーは速いので、このような動的にHTMLを生成する仕事を0.1秒などで高速にこなせます。しかし、アクセスが増えればサーバーの仕事量が増え、だんだん遅くなっていきます。インターネットを使っていて、アクセスが集中することでなかなか表示されないサイトに遭遇した経験は何度もあるのではないでしょうか。

従来通りのサイトで使われる技術は、たとえば、WordPressなどPHPを使ったもの、Railsなどで開発されたWebアプリケーションのようなものが挙げられます。

パフォーマンスのよいサイト

こういった技術で使われる、「サーバーサイドでHTMLを生成する処理」は静的なHTMLであれば必要はありません。静的なコンテンツ、静的なHTMLというのは、どんな状況でアクセスしても同じ内容を返すページのことです。つまり、静的なHTMLを表示する処理というのは、すでにできあがっているHTMLファイルをそのまま返すだけです。 そのため、サーバーサイドでの処理が必要なプログラムで構成されたHTMLに比べ、静的なHTMLはより高速に配信でき、パフォーマンスのよいサイトにつながるのです。

セキュリティ面で有利

静的なHTMLはセキュリティ面でも有利です。サーバーサイドで処理するプログラムがなく、データベースにもアクセスしないとなると、攻撃する隙がないのです。

インフラの選択肢が広い

また、もう一つ大事な理由として静的なHTMLは、どんなインフラでも配信しやすい（ポータビリティに優れる）という点があります。サーバーサイドで処理するプログラムは、それが実行できるサーバーやインフラを用意する必要があります。一度、運用を開始してしまうと、サーバーやインフラを置き換えることは大掛かりなプロジェクトとなります。

一方、静的なHTMLを配信できる環境はたくさんあります。ただのWebサーバーでも配信できますし、AWSのS3といったサービス、CDNサービス、そのほか次回以降に紹介するJamstack向けのホスティングサービスでもコピーするだけで配信できるのです。インフラを切り替えるにしても、基本的には新しい環境にコピーするだけで切り替え完了という手軽さです。

SSRやISRなどの技術

Next.jsは現在人気のあるフレームワークで、Jamstackの公式サイトでも紹介されています。しかし、最初に少し触れたようにJamstack専用のフレームワークではありません。 Jamstackを理解していれば、静的サイトジェネレーターとして使うことはできますが、使い方によってはJamstackではないアプリケーションになってしまい、Jamstackの特徴的なメリットが得られなくなります。

たとえば、Next.jsで提供される比較的モダンな手法であるSSR（Server Side Rendering）や、ISR（Incremental Static Regeneration）といった手法があります。これらはJamstackであると誤解されている場合がありますが、今回説明したとおり、サーバーサイドの処理があるものはJamstackではありません。サーバーサイドで処理が実行させるのであれば、その部分に関するセキュリティは従来のサービスと同等になりますし、インフラもその処理が実行できるものに限られてしまいます。Jamstackのメリットは完全な静的HTMLでないと得られないのです。

Jamstackサイトやアプリケーションに動的な機能を追加するには、サーバーサイドで動的にHTMLを生成するのではなく、次回以降解説するAPIとして分離して機能を足す必要があります。

とはいえ、SSRやISRといったNext.jsの提供する技術が悪いわけではありません。Jamstackではないというだけで、サイトやサービスによっては有効な方法ですし、もちろん従来型のPHPによるサイトはダメであるわけでもないのです。それぞれ特徴があるので、Jamstackの特徴を理解した上で、サービスによって採用するかどうか、組み合わせるのはどうかといった判断をしていくと良いでしょう。

2. ビルドプロセスで事前にHTML生成する

まずは静的なHTMLのメリットについて解説しました。次に、どのように静的ファイルを用意するのかについてです。静的なHTMLで構築するとしても、昔のようにHTMLをすべて手書きで用意するというわけではありません。

Jamstackでは、従来サーバーサイドのデータベースから取り出していたようなデータを、静的HTMLにできる限り多く埋め込んでおきます。それを実現するため、静的サイトジェネレーターを使って、静的HTMLを生成します。

静的サイトジェネレーターとは、データとテンプレートからビルドすることで静的HTMLを生成できるツールです。ここでいうデータは、JSONやYAMLといったテキストデータに加え、ヘッドレスCMSといったサービスのAPIから提供されるデータも含みます。APIから取得されるデータも埋め込んでしまうことで、ユーザーがページにアクセスした際、APIリクエストが不要になり高速に表示できます。

静的サイトジェネレーターは、数多くの種類があり、それぞれどんな特徴があるのかといったことは次回以降、解説します。ここで覚えておいていただきたいのは、このビルドによって事前にデータをできるだけ埋め込むことで静的HTMLにしておくことが、Jamstackにおける肝となる部分ということです。

ビルド時に一切データを埋め込まないのであれば、Jamstackではないといっても過言ではないでしょう。

ヘッドレスCMS

ヘッドレスCMSとは、コンテンツやファイルなどを管理する管理画面があり、コンテンツ構造を決め、登録するとコンテンツを取得できるAPIができるサービスです。 ヘッドレス（headless）というのは、コンテンツの見た目を表現するHTMLの出力機能を持たないことから、そう呼ばれています。

まとめ

今回はJamstackの現状と、ルールとして静的HTMLで構成すること、その方法について解説しました。次回は動的な機能をAPIとして分離すること、そして公開するためのホスティングサービスについて紹介します。