本投稿はJamstackその２ Advent Calendar 2020の15日目です。その1と比べてその2は過疎化しているので今からでも間に合いますよ！

はじめに

勢いで登録したもののいまさら見直してみると、

Next.js / Nuxt.js / Gatsby / Gridsome / Vercel / Netlify / Amplify / CDN / サーバーレス / ヘッドレスCMS 等々、関連する話なら何でもOK

ということで実際にNext.jsとかGatsby、CMS周りの話が多い様子。では自分は何について書こうかと考えたときに最近こんなツイートをしたことを思い出しました。

Jamstackって言わんとすることはわかるんだけどどうにもなんか腹に落ちきらないんだよな。これみたいにPrisma使ってバックエンドがDBだったらもはや普通のSSGで作ったシステムじゃん、と。じゃその違いは？みたいにもやる / “The Jamstack with Next.js and Prisma” https://t.co/iaSNKZbroE
— Keisuke Nishitani (@Keisuke69) 2020年12月13日

ここで紹介している記事を読んだときにそこはかとない違和感を感じたんですね。この記事ではJamstackとしてRDBを使ったサイトについて書かれています。このRDBへのアクセスの部分をPrismaを使ってやるって記事ですが、これってJamstackとは言えないのではないかと（RDBをAPIと解釈すれば別ですが）。

あとはこれ。

最近改めてJamstackって何だ？となってきている🤔
なんかこの言葉に惑わされてる気がしつつCMS比較をちょこちょこと進めてる
— Keisuke Nishitani (@Keisuke69) 2020年12月5日

というわけで、今回は改めてJamstackというものを自分なりに整理して、把握して、考えてみたいと思います。つまり技術的な内容ではなくポエム。全く役に立たない内容です。

Jamstackとは

まず、Jamstackという言葉を耳にするようになって久しいですが、そもそもの発信元による定義なんかをまずは振り返ってみたいと思います。

jamstack.org

このサイトにあるこのページにその辺が記載されています。JamstackというとJavaScript/API/MarkupのAcronymとされていたかと思いますが、意外なことにこのページではそんなことは一切書かれていません（要素キーワードとして出現はしますが）。

このページに書かれている内容を簡単にまとめると、

Webを速くし、セキュアにして、スケールしやすくするためのアーキテクチャ
開発者が好むツールとワークフロー上で構築される
プリレンダリングとデカップリングにより、より信頼性と弾力性をもって配信できる

このあたりを踏まえて超ざっくり説明すると、いわゆるサーバーサイドの処理やデータストアへのアクセスといったものはAPIとして利用してアプリケーション的な処理はJavaScriptで開発し、それをビルドプロセスで（静的サイトジェネレータなんかを使いつつ）静的ファイルとして出力するというものです。静的ファイルで構成されるので上であげた特徴を実現できるというわけです。

この場合、サービスとして提供するのに必要になるものは静的サイトをホスティングする場所だけですが、多くの場合はCDNを使って配信します。静的サイトであることは動的に処理をするよりは速く動作しますし、動的な部分がないことでセキュアになるとも言えます。また、CDNで配信することでより高速になりますしね。

静的サイトジェネレータ関連のフレームワークというとReactだとGatsbyが有名ですね。Vue.jsだとVuePressとかGridsomeとか。もともとはサーバーサイドレンダリングのフレームワークであるNext.jsやNuxt.jsでも最近はできます。

Jamstackは新しい何かなのか？

さて、この説明でも感じた方も多いと思いますが、Jamstackって僕の理解ではぶっちゃけただの静的サイトです。

JamstackがJavaScriptとAPIとMarkupのAcronymという話をしましたがJavaScriptとAPIは別にJamstackではなくとも昨今のフロントエンドであれば普通に存在します。この文脈におけるMarkupってのは未だに明確に何を指しているのか理解できていないですが、HTMLだったりテンプレートだったりのユーザインターフェースとなる部分だとぼんやり理解しています。

これら静的なものをCDNで配信するのも普通です。これまでもHTML、JS、CSS、画像などの各種アセットといった静的なものはなるだけCDNに乗せましょうってのが当たり前だったと思います。

ポイントはビルドにあると思っています。通常の静的サイトと異なるのはやはりモダンなツールセットを用いたビルドワークフローが含まれることだと考えています。これは動的サイトと異なりコンテンツの更新にあわせてそれを反映したファイル群を静的に出力するという特性上とても重要な点だと考えています。

基本的にはGitなりでコンテンツ更新をしたらWebhookなりGithub Actionsなりの方法でビルドをトリガーして再デプロイまでが1セットです。

結局、Jamstackとは何なのか

さて、Jamstackという言葉の提唱者はNetlifyのFounderであるMatt BiilmannとChris Bachですが、そのMatt Billmannと同じくNetlifyのPhil Hawksworthが執筆した『Modern Web Development on the JAMstack』というオライリーで配られている無償PDFがあります。ここからもわかるようにJamstackはNetlify発の用語と言えるでしょう。

ふと、Netlifyの創業とJamstackという言葉の誕生はどちらが先なのかな？と思って調べてみました。Wikipediaを見ると

会社の前身は、2013年にデンマークの起業家Mathias Biilmannが、サンフランシスコをベースとするコンテンツ管理のスタートアップであるMakerLoopの運営中に、静的ウェブサイトへの回帰が起こっていることに気がついたときに遡る。2015年、Biilmannは、デンマークのクリエイティブサービスエージェンシーの役員として働いていた幼馴染のChristian Bachを呼び、新しいベンチャーに参加しないかと誘った。2015年3月、NetlifyはMakerLoopの製品の1つとして公開された。

2017年12月19日、MakerLoopはデラウェア州務長官（英語版）に修正証明書（Certificate of Amendment）を提出し、社名をNetlifyに変更した。

ということなので元はMakerLoopというスタートアップのプロダクトの1つとして2015年3月にリリースされて、その後2017年12月に社名をMakerLoopからNetlifyに変更したってことのようですね。

ではJamstackという言葉がいつ世に出たかというとはっきりしたことはわからないのですが、Wikipediaによると同じく2017年12月に公開されたこの記事が一番古そうです。というわけで社名変更と同時にキャッチーな用語として定義したのかもしれません。

つまるところこれまでもアーキテクチャとしては存在していたものに対して定義したにすぎないNetlify発のマーケティング用語に近いというのが僕の認識です。でも、これは決して非難しているわけではなくて、こういった汎用化された用語が定義されることでぼんやりとなんとなく同じような共通認識を持つことができるというのは大事だと思っています。一方でこの『ぼんやり』で『なんとなく』であることから具体的に話をしていくと細かい部分で各々の認識が異なるという事態が生じるわけです。

これは過去にクラウドとかサーバーレスでも同様の道を辿ってきたものですね。そのたびにこれはクラウドなのかどうか、そんなのはクラウドじゃない、とか。サーバーレスも同様です。おまゆう案件かもしれませんが。

1つだけ言いたいこととしてこの手の用語における細かい定義なんてのは正直なところどうでもいいと思っています。それを厳密に定義して分類したところで何か生まれるのでしょうか。何も生まれません。大事なことは自分のやろうとしていることにそのプロダクト、サービス、概念がメリットをもたらすかどうかだけかと思います。

開発者としてやるべきことはその要素技術をしっかりと正しく捉え、自分のユースケースと照らし合わせて選択することです。それが結果的にクラウドであったりJamstackであったりに過ぎないと思っています。

先の記事も同様です。RDB使った構成に違和感を感じたと書きましたがバックエンドとしてRDBを使ってようが、よくあるマークダウンファイルとしてブログ記事を入稿するパターンでも別になんでもよくて。意味があってそれを選択しているのであればそれがJamstackの定義と照らし合わせてどうかってのは関係ないのかな、と。