静的なコンテンツはCDNで配信し、動的なコンテンツはJavaScriptをベースにAPI経由で表示させることで、高いパフォーマンスとセキュリティ、そして低コストな開発を実現するという話題のサイト構築技術Jamstackについて、「当社はJamstackの会社」と公言するピクセルグリッド テクニカルディレクター 高津戸壮氏に、TechFeed CEOの白石俊平がお話を伺いました。
今回話を伺ったエキスパート
フォローしよう！
–最初にJamstackの概要を教えていただけますか。Jamstackとは何でしょうか。
Jamstackの提唱者は、Netlifyというホスティングサービスをやっている会社のマット・ビルマン(Mathias Biilmann)という人で、2016年に「これからJamstackで作っていこうぜ」みたいなことを言い出したんです。JamstackというのはJavaScript API markupの略でJam、これを開発の中心とする技術スタックといった意味です。それまで、ある程度の規模のWebサービスやWebサイトを作るときにはCMSに組み込んだりバックエンドありきが一般的だったんですが、Jamstackでは、JavaScriptであらかじめ静的なHTMLをドカンと作って、それをCDNにホスティングさせてWebサイト一式を作りましょうという設計思想なんです。そういった設計をJamstackと呼んでいます。
どうしてそれをやろうとなったかというと、サーバサイドにバックエンドの仕組みがあると、けっこうなセキュリティリスクがあるんですよね。RubyでもWordPressでもPHPでも何でも、サーバサイドにおいて何かを作っている以上、脆弱性が突かれて問題になってしまう可能性があります。それに対して、静的なHTMLをあらかじめ作ってCDNに置いておくだけなら、バックエンドの仕組みに介入する余地がかなり少なくなるので、セキュリティリスクが減ります。
あとは、CDNに置くことで高速に配信できるところが特徴です。バックエンドの仕組みありきでもできなくはないですが、そのための仕組みを作ったり使ったりする必要が出てきてしまいます。APIから取ってきたデータをHTMLに読み込んでCDNにデプロイするようにすると効率的な開発ができるというところがポイントで、それがJamstackなんです。それが広まって、今では主要な開発方向のひとつになっているかなと思います。
–JavaScript＋APIマークアップというのは、シングルページアプリケーション(SPA)がAPIを使ってデータを取ってくるのとは違う話ですか?
そうですね。Jamstack以前のトレンド、とくにフロントエンドでは、何をやるにしても「SPAをがんばって作ろう」みたいなの風潮があったと思うんですよ。それがトレンドというか、効率なりパフォーマンスを考えるとかなり良い方向性だよねみたいな。言ってみればJamstackは「そんなにSPAにすることなくない?」というものです。
もちろんSPAが向いている設計はあります。でも、たとえばコーポレートサイトを作るならSPAにする必要は全然ないですよね。とくに商品情報などは決まったデータがあって、そんなに頻繁に更新されるものではありません。バックエンドありきの旧来の仕組みでアクセスして、APIリクエストして取ってきたデータをJavaScriptで画面に表示させる形でSPAを作ってもできますが、「それよりも最初から埋めといたほうが効率的じゃない?」というのがJamstackです。CDNで高速に配信できる上に、画面自体は本当にただのHTMLなんで、これ以上安全で高速に配信できる方法は現実的にないだろうみたいな感じですね。
–APIをJavaScriptで動的に呼び出すのではなくて、最初にAPIを1回呼び出して、でき上がったDOMをダンプして静的なHTMLとして出力する、というやり方ですか?
端的にいうとそうですね。要するに最初にビルドしてしまうんです。SPAの場合はビルド時にAPIにアクセスしませんが、Jamstackの場合はサイト一式をビルドするために全部データを取ってきてHTMLを作って、それをCDNにデプロイ、という流れです。
–なるほど、わかりました。その利点は、先ほどおっしゃっていたセキュリティリスクが低いことと、パフォーマンスが良いということですね。
そうですね。加えて開発のしやすさもあります。バックエンドがある仕組みでは、ローカルで環境を作るなどいろいろと手間がかかりますが、Jamstackのローカル開発環境はNode.jsが動いてビルドできれば、つまりフロントのコードだけ見られればいいところがあって、Netlifyはその先駆けになっています。
また、開発者の開発体験(Developer experience)を上げたいという思想が入っていて、Netlifyにはメインブランチにプルリクエストを投げると、そのプルリクエストの内容でビルド結果のURLが作られるプレビュー機能があります。バックエンドがある仕組みだと、このためだけにDockerインスタンスを立ち上げる必要があったりすると思いますが、Jamstackなら、とりあえずその時点でビルドしたものをどこかに置いておけば済みます。そういった開発者の視点での体験の向上もメリットとしてあるかなと思います。
–APIでデータを取ってきてHTMLを作るということで、APIが必要ですよね。それはどのように用意されているのでしょうか。
Jamstack界隈だとヘッドレスCMSを使うことが多いです。ヘッドレス”CMS”といってもただデータを作ってくれるだけの存在で、日本で有名なのはmicroCMS、海外ではContentfulなどいろいろありますが、とても便利です。たとえば、最もメジャーなCMSのWordPressだと、WordPressのPHPにコードを埋め込むことがありますが、そうなるとバックエンド側の実装と混ぜる必要があります。対してヘッドレスCMSではAPIが完全に分離されているので、開発がしやすい利点があります。また、ヘッドレスCMSはヘッドレスCMSで競争があって、ブロック状にコンテンツを積むのに最適なUIが作られたり、ドキュメントも整っていたりと、どんどん便利になってきていますね。
また、ヘッドレスCMSを使うことで融通が利きます。たとえば普通のCMSだとCMSのやり方に沿った方法で実装する必要がありますが、ヘッドレスCMSというのはJSONビルダみたいなもので、ただJSONを返してくれるだけなので、データベース設計を簡単にしてくれる存在ですね。同じことはJamstackではなくSPAでもできなくはないですが、よりJamstackに向いたサービスだと思います。
–Jamstackを使用した具体的な開発例とその構成を教えていただけますか？
当社(ピクセルグリッド)のフロントエンド関連記事配信サービス「CodeGrid」自体もJamstackで作られています。構成としては、サーバがNetlifyで、ログイン機能などを付加しています。サービスとしては週に一度、記事が配信されるので、週1回はビルドが走って、出力を表示するイメージです。Eleventyというライブラリを使っていて、著者情報のようなデータベース寄りの情報については、HygraphというヘッドレスCMSのデータベースを使っています。
あと、他の事例ではホスティングとしてAWS Amplify、Cloudflare、ヘッドレスCSMとしてmicroCMS、Prismic、ライブラリとしてEleventy、Gatsbyあたりを要件に合わせて組み合わせる感じで作るなどしました。コーポレートサイトや読み物のサイトで、お客さんのほうで自分でコンテンツをCMSに入力してもらって運用するというような形が多いです。
–ヘッドレスCMSの場合、APIの裏側には従来のバックエンドがあるのでしょうか。データベースがあって、普通のサーバサイドのアプリケーションがあって、APIを公開しているみたいな感じですか?
そうですね。たとえばmicroCMSの場合は、microCMSに登録するとユーザがスキーマのようなものを定義できます。ブログ記事なら「タイトルと本文と日付」といった3つのデータを繰り返すスキーマを定義してトークンを付けてURLを投げると、用意されているREST APIでデータが取得できるという、単純に言うとそういうことをやってくれるサービスです。バックエンドをたとえばPHPなりを使って、RESTなりGraph APIでデータが取れるようにしてもよいのですが、運用面で結局は管理画面を作らないといけない。それが簡単にできるのがヘッドレスCMSです。ただ、用意されている管理画面を使うことになるので、要件に合っているヘッドレスCMSを使うみたいな検討は必要だとは思いますね。
–なるほど。動的部分の少ないサイトにJamstackを使うのはかなり優れた選択肢に聞こえます。動的なサイトって実はWebサイト全体ではほんのわずかですものね。では、Jamstackの課題は何でしょうか。
課題はいくつかあると思います。まず、ビルドするときは全部のHTMLが生成されるので、変更部分が少しであっても全部ビルドしてデプロイしないといけないんです。自動化してCIにやらせるにしても、サイトの規模が大きくなると時間がかかるようになる。バックエンドで随時画面を作って返すタイプのCMSと比べると、場合によっては10分待たないと確認できないとかになりえるので、仕方ないですが微妙に辛いところですね。ただ、そういう問題を頑張って解決しようとしているプラットフォームもあります。たとえばGatsbyというフレームワークはGatsby CloudというGatsby専用のホスティングサービスを持っていて、登録してGitにコミットすると差分だけを取ってきてビルドし直すことができます。
もうひとつの大きな課題は、静的なHTMLを作ってデプロイするアプローチなので、動的な部分を設計上どうするべきかを考えないといけないところですね。たとえばユーザーが自由にレシピを投稿できるレシピサイトであれば、毎秒毎秒コンテンツが追加されることになります。そうなると、現実的に毎回全HTMLをビルドして作るわけにはいきません。考えられる主要な方法として、そこだけサーバサイドレンダリングで今までどおりにバックエンド側で処理したものを随時返すようにするか、もしくはそこだけSPAみたいにするかという2つのアプローチがあるんですが、たとえばNext.jsというフレームワークではそういうのが柔軟にできるようになっていますね。画面ごとに、リクエストに対して随時HTMLを作って返すサーバーサイドレンダリングという方法にするのか、あらかじめHTMLを作っておくのかというのを選べたりします。
でも、サーバサイドレンダリングをする場合は、これまでのPHPとかでやっていたようなユーザーのリクエストごとに画面を作って返すわけなんで、今日話したようなメリットが適用されないんですよね。あらかじめHTMLにしてCDNに置いておけば、速いしセキュリティも安全…と話してたやつです。Jamstackという静的に作るアプローチでも、Webサイトによってはそういう静的に作れない部分も混ざってくることはあるので、その動的な部分をどうするかという課題がけっこうややこしい部分だと思います。
そうなってくるともはやJamstackとは言えないのではないか?という話もありますが、Jamstackという言葉が生まれて以降、Jamstackを実現するフレームワークやプラットフォームが発展して、そういった動的な部分を解決するための方法が利用できるようになったという感じですかね。
–最後にJamstackの今後の展望について、今後どうなっていくでしょうか。
弊社ピクセルグリッドは、Jamstackがいまのように広まる前から「Jamstackの会社です」と銘打ってるんですが、その後、開発の手法としてJamstackはすでに広く周知されたと感じています。全体の設計の中での選択肢のひとつとして定着してきたのではないでしょうか。今後を考えると、さらにコンテンツを配信しやすい仕組みが提供されて、開発者的にもコンテンツを編集するエンドユーザーにとっても、より作業がやりやすくなっていくと良いのでは、という気がしますね。
--なるほど。貴重なお話をありがとうございました。
Takazudoさんも執筆するオンラインマガジン「CodeGrid」はこちら！
