Modern Web Development on the JAMstack を読んでまとめた

JAMとは

• JavaScript / API / Markup
• Jamstackとは
  • 特定の技術を指す言葉ではない
  • いわばムーブメントである
• いろいろなガイドラインがあり、その中で選択をすることになる
  • ブラウザのためのJavaScriptは必須になるが、それ以外の言語も使える
  • いろいろなOSSを選択できる
• 新しいアイデアもあれば、古いものもある
  • 最近になってやっと選べるようになった技術もある

開発効率とパフォーマンス

• Jamstackなサイトとは
  • 世界中にデプロイされ、負荷耐性がある
  • Gitベースで開発者フレンドリー
  • APIによってサービスを利用する
  • 事前にビルドされ、最適化されている
• 最後の項目が特に重要
  • クライアントが動的に画面を組み上げるべきではないし
  • サーバーもリクエストの度にコンテンツを生成すべきではない
• Jamstackたるもの
  • コードとコンテンツは同じリポジトリで管理され
  • そこに変更があればビルドが実行され、HTMLや他のデータを生成する
  • それらはCDNで、ユーザーに最も近いところへ配置される
• こうすることでネットワークのレイテンシを極限まで下げられる
• リポジトリに対する変更にはじまり、CDNのファイル更新に終わる
  • この流れが新しいポイント
  • キャッシュのパージを待つ必要もない

バージョン管理によるアトミックなデプロイ

• Jamstackでは、コンテンツすらもGitで管理する
  • つまりデータベースが不要になる
• この考え方で、常にデプロイがアトミックなものになる
  • Gitのブランチを切り替えれば、それがステージングになる
• そういう意味では、もはや静的ではなく、日に数百回も更新される

Jamstackをやっていく

• ワークフローに参加するのはエンジニアだけではない
  • Gitに詳しくない人もいるだろう
• そのためのCMSなどもある
  • Gitを意識することなく、コンテンツの作成や修正ができる
• ビルドのタイミングでそれを自動化することもできる
  • 特定のソースから情報を取ってくるなど
• 全てを巻き込むことで、すべての履歴を管理できるようになる
  • 必要な単位・タイミングで、Gitのリポジトリに入れればいい

API

• 単なるHTMLよりも複雑なことをやる場合に必要
• 従来はセッションを保持して、サーバーが状態を保っていた
• これらは、専用のマイクロサービスによって代替される
  • 支払いはStripe
  • 検索はAlgolia
  • etc...
• すべてを1回呼びきりで副作用のないAPIにする
  • スケーラブルにするため
• とはいえ認証などはあるだろう
  • JWTを作成して、ブラウザに保存するとよい

Smashing Magazineのケース

• 歴史あるWebマガジン
  • https://www.smashingmagazine.com/
• 2017年の末、Jamstackに移行した
  • 後の章でそれを解説する

では本編へ

• Jamstackを知るためには、実際にやってみるのがよい
• 特別なスキルは必要なく、既にできることの組み合わせである
  • ただしサーバーなしで
• 最初にWebに触れたあの頃を思い出してほしい
  • いかに負担をかけずにコンテンツを制作するか
  • それが魅力あるコンテンツ、UI作りにつながる

モノリスアーキテクチャ

• 誰もが通った歴史
• しかしサーバーがクライアントの形まで決めてしまう
• 分離されていないので不必要に複雑化していく
• 現世においては、オーバーエンジニアリングなところすらある

現状維持のリスク

• 変化よりも現状維持のほうが、得てして簡単である
  • その変化のためにあらゆるリソースが必要になるから
• しかし今こそ、変化の時がきたのだと思っている
  • 現状維持のほうがコスパが悪くなるラインがきたということ
• 既に前に進む選択をしている人たちもいる
  • ブログやOSSのドキュメント、イベント告知ページなど
• この流れがやがて大きくなって、ECやサブスク系にも広がっていくはず
• オンライン人口がこれからもずっと増えていく
  • そのために、トラフィック増大にも耐えられ
  • あらゆるネットワークでも快適に閲覧でき
  • あらゆる言語、デバイスで利用できる
  • セキュリティも万全な
• そんなWebを、Jamstackで作りたい

その名の由来

• 既にあるものを組み合わせて名付けただけ
  • 名前というものは便利
• その背景にあるトレンドとなっている技術たち
  • 静的サイトジェネレータ
  • SPA
  • ビルドツール
  • 用途に特化したAPIのエコシステム
  • PWA
  • etc...
• J: ブラウザのランタイムとしてのJavaScript
• A: データベースを意識しない、個別のHTTPのAPI
• M: 事前にビルド済のHTML

JavaScript

• 1995年に10日ぽっちで作られたとは思えないほど成熟した
  • ほかの言語からコンパイルされることもあるほどに
• ランタイムのVMとして、Jamstackでも利用する
  • ブラウザはもはやWebにおけるOSである

API

• もともとのJavaScriptには、外部のサーバーとやり取りする機能はなかった
  • それが今やCORS、WebSocketなどなど
  • OAuth2やJWTなど認証の仕組みまである
• APIは、Webの可能性をそのまま広げる
  • 今やだいたいのものはAPIでまかなえる
• これを利用しない手はないという意味で、Jamstackでも利用する

Markup

• HTMLはもともと文書を読むためのものだった
  • いうなればWebサイトは、ただのフォルダだった
• やがて、データベースの情報を取得して返すものになった
  • しかしこれが遅い
  • 静的なサイトに比べると複雑になる
• けど、あの頃はそうするしかなかった
• しかし今は違う
  • JavaScriptもあるし、クロスドメインでAPIも利用できる

Jamstackのプロジェクト

• 世界中で様々なタイプのプロジェクトがデプロイされてる
  • 数ページのものから、数千ページのものまで
• その種類について見ていく

巨大なサイト

• 事前にビルドする際の問題は、そのページ数
  • ビルド時間をいかに短くするかが問題
• サイトによっては、10分すらも待てないことがある
  • ビルドツールの高速化も進んではいるが・・
• Jamstackを採用できるかどうかは、このサイクルをどう捉えるか
  • コンテンツの公開スケジュールに縛られない場合は、多少はマシ
• 数千ではなく、数百万くらいのページがある場合のみ、要検討になると考えている

ハイブリッド

• サイト、ブログ、アプリなど、様々なユースケースがある
• 従来のアーキテクチャでは、フロントエンドはバックエンドと密結合していた
• Jamstackなら、そのどんなケースにも対応できる
  • バックエンドに縛られないから

まとめ

• Jamstackがハマらないプロジェクトは、そんなに多くないはず
  • ツールやエコシステムが成熟していくにつれて、もっと広まっていくはず

物事を単純化する

• 数多の抽象化によって、我々はいろんなことができる
• しかし抽象化は時に危うい
  • 我々の手が届かないところで何が起きているかわからない

コスト

• コストにはいろんな面がある
• そしてそれはアーキテクチャに大きく依存する

スケールさせるために

• スケールについてもっと詳しく
• どれだけ緻密に見積もっても、サイトのトラフィックは突然跳ねる
• それに備えて監視したり、スケールできるように構成することをしていたはず
• これがそもそもコストであり、好ましい状態ではないということ

パフォーマンス

• 開発者なら誰でも、パフォーマンスを気にする必要がある
  • ネットワークの信頼性の違いや、回線速度なども
  • デバイスの違いについても
• パフォーマンスの指標がある
  • FirstMeaningfulPaint / TimeToInteractive
• WPO: WebPerformanceOptimizaion
  • https://wpostats.com/
  • たくさんの事例が公開されてる

セキュリティ

• Jamstackによってシンプルな構成になると、セキュリティも強固になるおまけがつく

どうやって勝つか

• 複雑性を減らすことの意義について学んだ
• 基本的には受け入れられるべき方針だが、もしかしたら開発効率が気になるかもしれない
• 開発効率や開発体験は重要である
  • それによってプロジェクトの質も左右される
  • 長期的に見ればなおさら
• しかし開発者体験よりも、ユーザー体験のほうが重要
• 開発体験もそこまで悪化しないと思っている
  • 馴染みのツールを組み合わせて使うだけなので
• Jamstackは、どちらの体験も良くすることができるはず

プロジェクトのセットアップ

• サーバーもデータベースも不要な場合、Jamstackはただのフォルダである
• しかしコンテンツはGitで管理されているほうがよい
  • たとえ個人プロジェクトだとしても

コンテンツマネジメント

• コンテンツがないとサイトは成り立たない
• そんなコンテンツをどのように管理するか

サイトジェネレータ

• コンテンツを実際のHTMLに変換するところ
• サイトジェネレータはいろいろある
  • 昔はJekyll一強だったが今はたくさんある
  • https://www.staticgen.com/
• その中からどれを選ぶかが重要
  • 選ぶポイントを見ていく

自動化する

• Jamstackにおいて、ビルドの自動化は必須
• ビルドして自分でデプロイすることも不可能ではない
  • ただすぐにスケールしないことに気づく
• GitのリポジトリからWebHookでビルドを実行するのがよい
  • GitHubやGitLabやBitbucketなどにはある
• Gitのpushに対応して、ビルドプロセスを起動する

CDNを選ぶ

• どれだけ技術が進歩しても、時間と空間はまだ克服できない
• コンテンツの提供時間は、ビルドを事前に済ませることでほぼ0にできる
• しかしコンテンツとの空間的な距離は埋められない
• そこで、全世界に配置されたCDNを使う
• CDN事業者の選び方を3つ紹介する

APIを提供する

• あらゆるものがAPIで提供される昨今
• しかし、それらのAPIが本当に信頼できるのかは悩み
  • ただこれは、自作する場合でも同じ悩みになる
• ただ言えるのは、APIドリブンのアーキテクチャや開発手法のほうが柔軟であるということ
• たとえばECサイト
  • まず負荷への体制だがこれは問題ない
  • そして画面レイアウトなどの柔軟性は、従来のECパッケージを使ったサイトとは比較にならない
• しかしECサイトは動的である
  • 検索やセール情報、在庫の確保など
  • これらはすべて専用のコンポーネントでまかなう
• ECサイトのビルドの例
  • CMSを更新すると、ビルドがはじまる
  • 同時に、検索エンジンへメタデータを送る
• ECサイトのランタイムで動くJavaScript
  • 検索フィールドに文字を入れたら検索APIをたたく
  • カートに商品を入れたら、購入用のAPIをたたく
  • etc...
• このように、APIを組み合わせてサイトを形成していく

マインドセットとアプローチ

• Jamstackでプロジェクトを進めるためには、まずそれが何かを知る必要がある
• 静的にサイトを配信すればそれはJamstackだ、というのは間違い
  • 間違いというか、端折りすぎた説明
• 真に静的なサイトには、動的な部分は存在しない
• Jamstackでできたサイトには、動的な部分も組み込める
  • そして、それを支えるビルドの自動化や、外部APIやサービスまでがセット
• ベストプラクティスを6つ紹介する

1. CDNを使う

• CDNを利用することで得られるメリット
  • 1. 物理的に近いサーバーからコンテンツを配信できてパフォーマンスがよくなる
  • 2. 冗長化が自動的に成される
  • 3. 自分たちのインフラがSPoFにならない
• 突然のトラフィック増にも、CDN事業者が対応してくれる
  • これを自分たちでやるのはすごく大変
  • そして動的なコンテンツの場合は、さらに難易度が上がる

2. イミュータブルでアトミックにデプロイ

• 事前に静的なコンテンツを用意することで、改善速度もあげられる
• ただしそのためには、たくさんの素材を、すばやくデプロイできなければならない
• リリースサイクルをいかに効率的にするかが、コンテンツが増えると課題になる

イミュータブルなデプロイの位置づけ

• Jamstackに移行することは、イミュータブルなデプロイを行うに等しい
  • ビルド時に利用するデータと、その後で利用するAPIも分離されてる
• これらの性質があるからこそ、イミュータブルなデプロイが可能になるとも言える

アトミックなデプロイ

• イミュータブルに生成されたコンテンツは、アトミックにデプロイされる
• アトミックなデプロイとは、すべてをまとめてデプロイすること
  • 変更した一部分の差分だけを更新するのではなく
• CDNはファイルの差分をハッシュなどでチェックでき、無駄なファイル転送を省いてくれる
• Jamstackは、こうした前提に基づいて、あらゆる複雜性を排除するデザイン

3. すべてをバージョン管理する

• コードベースの管理に、Gitを採用することは一般的
• だがその考え方をデプロイにまで活かすことは、あまりされていない
  • Herokuはそれをやっている例で、人気を博した
• デプロイまでバージョン管理下に置くことで、不慮の事故を防ぐことができる
  • ステートフルなデータベースがあるとそれも難しいが、Jamstackにデータベースは存在しない

4. 自動化とツール

• 単なる静的なサイトでなく、ビルドとデプロイの自動化までやるのがJamstackのカギ
• 静的サイトジェネレータを使うことは、そもそもその自動化への第一歩でもある

5. エコシステムを利用する

• 価値があり、利用できるツールは、どんどん利用していく
  • 便利なツールやサービスが急速に生まれている
• Jamstackを、単なる静的なサイトのためのアプローチと言えなくなりつつある
  • これらのツールやサービスを利用することで、機能追加し動的にできるから
• そんなサービスを、Jamstackのプロジェクトで採用するためのポイントを紹介する

6. FaaSで最後の穴を埋める

• これまで見てきたように、たくさんのサービスがある
• 基本的にそれらを再実装する必要はない
• とは言え、どうしても実装する必要がある場合もある
• そこで使えるのが、Functionのサービス
  • サーバーレス関数とも

脱モノリスするために

• Web開発者は、その速度を落とすことなく学び続けなければならない
• ただ、すべてのことに精通する必要はない
• 外部サービスを利用するということは、責任を預けるということ
  • 最初はそれが落ち着かないかもしれない
• ただし、そうすることで得られるものも多い
  • 安心感、開放感なども
  • 彼らも素人ではない
• 自分たちの領域にその分だけ集中できる
• どの領域を3rdパーティのサービスに任せるかは、一考の余地がある
  • 利用規約は適切か
  • サービスレベルの保証はあるか
  • 金銭的なコスト、実装のコストはどうなるか
• ただ基本的な考え方として、事業者もビジネスでやっていて、常に進歩している
  • 自分たちで実装するよりも、任せてしまうほうが、往々にして良い結果になる
• 次の章では、それを実践した経験について触れる

ケーススタディ: Smashing Magazineの場合

• Smashing Magazineは歴史あるフロントエンドの情報サイト
  • https://www.smashingmagazine.com/
• 2017年の末、Jamstackに移行した
• この章は、そのショーケースである

チャレンジ

• サイトは10年も運用されていた
  • 数千もの記事、20万のコメントがあるWordpressの本体
  • 本やワークショップを販売するShopifyのEC
  • Ruby on Railsでできたジョブボード
  • カンファレンス用のPHPのスタック
• ビジネスの成長にあわせて様々な機能が追加されてきた
• しかし、もうこれ以上は厳しいという段階だった

キーポイント

• パフォーマンスと安定性、セキュリティを改善したい
• 同時に、メンバーシップの概念を導入したかった

ツール選び

• それらを実現するため、選ばれたのはJamstackでした
• そのコアとなる静的サイトジェネレータや、フロントエンドのフレームワークを選ぶ

コンテンツの移行

• まずは既存コンテンツをエクスポートすることからはじめた
  • いろんなデータベースに別個に入っていたものを、テキストファイルとしてディレクトリに整理
• WordpressからHugoへ移行するためのちょっとしたツールを使った
  • RSSフィードを使ったツールも
• コンテンツの移行は、それぞれのプロジェクトごとにやり方を変える必要がある

コンテンツの構造

• それぞれの記事はテキストファイル
  • YAMLのfrontmatterがあって、本文が続く
• 10年分の記事はかなりの数があるが、それでもGitで管理できる
  • Lunuxカーネルなんかに比べれば小さい
• しかし画像などのアセットはGitに入れられなかった
  • サイズが大きすぎて、cloneするのが大変
• それらは新しいCDNに置き、パスなどの構造だけをGitで管理するようにした
• 軽量なサイトを作るためには、これがベストな選択

大規模サイトであるがゆえ

• Victor Hugoに移行してからの開発で問題になったことが1つある
  • テンプレを変更した際の自動リビルドが遅いこと
• それを回避するため、Gulpを導入してスクリプト化した
  • 作業時には、すべてではなく100くらいのビルド済の記事で構成されるサイトとした
• こうすることで、ローカルでの開発にHugoで毎回ビルドする必要がなくなった

コアを作る

• だいたいのスケルトンができてきたので、コア部分を作ることにした
  • 頻出パターンなど、サイトのテーマのメイン部分のこと
  • テンプレで使えるパーシャルなど
• 事前にビルドするがゆえに、全記事をイテレーションして抽出するなどの処理もできる
  • ランタイムでこれをやると、パフォーマンスがすごく悪い
• Hugoはテンプレのフィルタが優秀で助かった

検索

• 検索は事前にビルドできない
• ここではSaaSとしてのAlgoliaを利用した
• 競合としては、Lunrがあった
  • こっちはインデックスを生成して、静的なファイルとして利用できる
  • ただ大規模サイトには向かないと判断
• ビルドの過程で、Algoliaへインデックスを送信するようになっている
• フロントエンドはPreactとReduxで構成
  • `data`属性がついた要素に、Preactのアプリを描画する
• JavaScriptが使えない環境では、Googleのサイト内検索にフォールバック

コンテンツ管理

• Jamstackでのコンテンツ管理は、いろいろなやり方がある
• しかし中でも、ヘッドレスCMSの利用が革新的
  • https://headlesscms.org/
  • 種類としては、APIベースのCMSと、GitベースのCMSに大別される
• APIベース
  • 専用のGUIによってコンテンツの編集をするもの
  • 事前にコンテンツの型やリレーションを定義する
  • ContentfulやDato CMS、GraphCMSなどが有名
• Gitベース
  • シンプルにGitHubなどの連携するもの
  • Netlify CMSやCloudcannon、Forestryなどが有名
• APIベースの利点は、さまざまなクライアントに、さまざまなデータを返せること
  • ただし、データの整形の手間が必要で、事前ビルドの時間が増える
• Gitベースの利点は、ディレクトリがそのままソースになるところ
  • 普段使っているツールやスクリプトがそのまま使える
• Smashing Magazineでは、Netlify CMSを選んだ
  • ビルドの時間が短くなる
  • 普段使いのエディタでコードのようにコンテンツを編集できるのがよい

Netlify CMS

• 従来のCMSは、CMSを使ってサイトを構成するというものだった
  • Netlify CMSでは、サイトがCMSを使える（データだけを引き出す）
• 特定のディレクトリに、同じ種類のコンテンツを格納し、コレクションとして扱う
• コンテンツを作成する画面は、ReactでできたSPAになっている
  • プレビュー画面などは、プラグインで機能を拡張できる
  • 自分でコンポーネントを用意すれば、独自のデザインでのプレビューも可能

大規模サイトのためのCMS

• NetlifyはGitHubのAPIを使ってコンテンツを取得する
• ただし大規模サイトにおいては、画像などのアセットは同様に管理しないほうがよい
• そのような場合のに備えて、Algoliaとの連携や、CDNへのファイルアップロードができる
• Netlify CMSでは、この拡張性によって、Gitベースでありながら大規模サイトにも対応できた

ユーザーとロール

• モノリシックな構成の場合、ユーザーの認証ももちろん組み込まれているはず
  • Smashing Magazineでも、複数のサイト向けに別々のユーザーの概念があった

EC

• Smashing Magazineの収入を支えるのがEC
• これまではShopifyを使っていたが、今回の移行で、GoCommerceというOSSを作った
  • https://github.com/netlify/gocommerce
  • 商品カタログのパスを渡して購入状態を作るAPIと、その購入に対する決済トークンを用意するAPI
  • 決済方法はPayPalかStripeから選べる
• ビルド時に商品のカタログをHugoで生成し、それを利用する
• Preactのフロントエンドでカート情報を保持しつつ、裏でそのAPIを叩く
• 購買フローを自由に設計できるのが強み
• この仕組みはデモのリポジトリもある
  • https://github.com/netlify/netlify-gocommerce-widget

メンバーシップとサブスク

• Smashing Magazineには、3段階の購読プランがある
• それによって、今まで紹介してきた各機能が協調するようになる
• そのための橋渡しをするために、AWSのLambda関数がある
  • 購読のタイミングで、ユーザーを認証する
  • そしてメールの購読サービスに登録し、Slackに通知
  • Stripeで定期購読するよう設定する
  • 最後に、認証サービスのユーザー情報も更新する
• これらの処理はシークレットの問題で、クライアントサイドではできない

GoCommerceでメンバー割引

• GoCommerceにも、JWTトークンのメタデータとして、購読プランを送るようにする
  • GoCommerce側では、割引設定が書かれた設定ファイルを見ている
  • それによって、金額の割引が可能になる
• GoCommerceと、割引設定はあくまで疎結合であることが重要

ジョブボードとチケット

• ジョブボードも、メンバー割引と似たようなイメージでGoCommerceで対応した
• 仕事を投稿する用の商品をGoCommerceで購入する
  • すると、WebHookにリクエストが発行されて、ジョブボードを更新する
• WebHookはAWSのLambdaで受けるようになってて、それによってMarkdownファイルがGitHubにコミットされる
  • そしてそれが新たなビルドのきっかけとなり、ジョブボードのページが更新される
• 同様の仕組みで、イベントチケットを購入した参加者一覧は、Spreadsheetに転載されるようになってる

ワークフローとAPIゲートウェイ

• このケーススタディで学んだこと
  • 事前ビルドされたフロントエンド
  • いくつものサービスを疎結合で利用する
  • サービス間の取りまとめには、サーバーレス関数を使う
• これがJamstackでサイトを構成することの強みである
• そしてこれを支えるのが、確立されたワークフローとメンテナブルな構成要素
• サーバーレス関数での取りまとめは、ワークフローのためには必須であるともいえる
• NetlifyのCDNは、エッジでJWTを検証できる
  • そこで検証をパスしたら、各サービス用のトークンをスワップしたりもできる
• フロントエンドと同様に、各サービスも一緒にデプロイされるワークフローが、自動化されているというのが重要

サービスのデプロイと運用

• それまではHerokuにすべてをデプロイし、DBもそこに1つだけあった
• この構成に変えてからは、各サービスがそれぞれのデータを抱える
• マイクロサービスの連携において、共通のDBを持つことは推奨されない
• それぞれのサービスを橋渡しするサービスも、最終的にAWSのLambda関数になった
• それより大きな規模であったり、永続化層が必要な場合は、Kubernetesなどに移行するのがよさそうである

まとめ

• 静的なフロントエンドと、そこから複数のサービスを利用する構成へ移行した
• 自分たちで書いたサーバーサイドのコードは、たったの575行（3つのLambda関数）だった
• アクセス急増に備える必要もなくなり、本来のサービスと向き合う時間が増えた
• GitベースのCMSもうまくマッチしていて、日々の運用でもスクリプトで簡単にファイルを処理できる
• 急ごしらえのOSSにはまだ粗があるけど、これからに十分に期待できる

最後にもう1つ

• Jamstackの利点だけを並べて説明するのは容易い
• しかしそそれ以上に、大事な哲学があることに触れておきたい
• Jamstackは、真にWebのためのものである
• iPhoneが世に出たあとで、ジョブズはFlashをHTML5に置き換えた
  • そのときに、Adobeに向けた手紙を書いている
• だいたいこんな内容
  • Flashは現在ひろく普及しているが、あれはAdobeでしか動かない
  • Adobe専用のものになってしまっている
  • AppleもOSなど専用なものは作っているが、Webはオープンであるべき
  • なのでFlashは、HTML5やその代替技術で置き換えられるべき
• Webは誰の手も借りずに、コンテンツを公開できる唯一の場所
  • しかしそこで十分な品質やUXを提供できない場合
  • またFlashの二の舞になってしまう可能性がある
• GoogleのAMPなどの取り組みもあるが、あるべき姿ではない
• Webの競争力を、健全なWebを保つために、過去の問題を解決しつつ、前に進む
• そのためのベストプラクティス、ガイドラインであり制約であるのが、このJamstackである

現場からは以上です！

ちなみに、Jamstackな会社のサイトでもわかりやすく説明されてたりするので、よければそちらもどうぞ。（宣伝）

Jamstackとは？ | 株式会社ピクセルグリッド