JAMstackとは何か？Web開発に新しいアプローチ

サイト機能

• 企業・実績の各種項目による検索
• キーワード検索お気に入り登録
• お気に入り共有
• CMSでのデータ・記事登録

メディアサイトで必要な各データを検索できたりお気に入り登録できるなど、基本的な機能を備えています。

使用技術

• Nuxt.js
• HeadlessCMS
• サーバーレス
• Github Actions（CI）

基本的に使用した技術構成は上記です。
HeadlessCMSとサーバーレスを使いJavaScriptのフレームワークで構築する、いわゆるJAMstack構成になります。
※JAMstackの説明は後述
Github Actionsでビルド、デプロイに加え、チャットへの通知なども行っています。

JAMstackに取り組むことになった経緯は、通常のサイトやWordPressなどのCMSとは異なる技術を試す機会でもありました。自社サービスの制作では、技術選定が醍醐味の一つだと感じています。私たちは高速で動作し、OGPなども考慮しつつ、CMSで更新ができるサイトを目指しました。

以前にSPAやSSRの構築経験もあり、今回は高速かつ機能的にもSPAやSSRに劣らないJAMstack構成で開発することにしました。JavaScriptのフレームワークとして、複数人での開発を行うことやルールの共有を考慮し、Vue.jsベースのNuxt.jsを選びました。Nuxt.jsはVue.jsの構造に一定のルールが設けられており、効率的なロジック共有が可能です。

サーバーホスティングでは、コストを抑えつつ高速なレスポンスとスケーラビリティを考慮し、Firebaseを選択しました。また、Googleのサービスを利用していることからGCP（Google Cloud Platform）への移行もスムーズに行える利点もありました。

CMSには、Nuxt.jsとの相性が良いHeadlessCMSを選びました。HeadlessCMSは、フロント部分がなくAPIが作れるCMSといえます。今回は記事数に制限がなく、無料からスタートできる日本語UIのmicroCMSを選択しました。

以上が私たちがJAMstackに取り組むきっかけとなった経緯です。

冒頭で挙げている使用技術やJAMstackで開発を進めていくにあたり、単純に設計しただけでは想定できていなかったことや、やってみたからこそ掴めたそれぞれの特性や、メリットデメリットなどがありました。
そういったポイントを少しご紹介します。

JAMstackとは何か？Web開発に新しいアプローチ

Web開発において注目を集めているJAMstack（JavaScript, APIs, Markupの頭文字）は、革新的なアプローチです。JAMstackでは、Webサイトやアプリケーションの開発において、従来のサーバーサイドの処理を減らし、代わりにクライアントサイド（ブラウザ側）での処理を重視します。

JAMstackとSPA、SSRとの違い

ここから、JAMstackとSPA、SSRとの違いをメリット・デメリットに分けて紹介します。

SPA（Single-Page Application）

SPAは、ブラウザ上で動的なコンテンツを提供するためにJavaScriptを活用するアプローチです。サーバーからは必要なデータを取得し、ブラウザ上でそのデータを操作して表示します。

メリット

• ページ遷移のスムーズさ
• ユーザー体験の向上

デメリット

• 初回読み込みが遅い場合がある
• SEOに課題がある（クローラーがJavaScriptを解釈できない場合がある）

SSR（Server-Side Rendering）

SSRでは、サーバーサイドでページのコンテンツを生成し、クライアントに返します。ブラウザはレスポンスを受け取り、そのまま表示します。

メリット

• 初回読み込みが速い
• SEOに強い

デメリット

• サーバーの負荷が高くなる可能性がある
• ページのパフォーマンスに依存する

JAMstackの採用には以下のようなメリットがあります。

高速化

JAMstackでは、事前に生成された静的なファイルを提供するため、読み込み速度が向上します。サーバーサイドでの処理が不要なため、レスポンス時間が短くなります。

セキュリティの高さ

静的なコンテンツの提供に特化したJAMstackは、セキュリティリスクが低いといわれています。CDN（コンテンツ配信ネットワーク）を活用することで、DDoS攻撃やセキュリティハッキングなどからの保護が強化されます。

運用コストの削減

JAMstackでは、サーバーの管理やスケーリングにかかるコストを削減できます。サーバーレスな環境を活用するため、インフラストラクチャの管理にかかる負荷が軽減されます。

JAMstackの採用には、以下のようなデメリットも考慮する必要があります。

双方向な要素を取り入れられない

JAMstackは静的なファイルの提供に特化しているため、動的な要素やユーザー入力による双方向の操作には制約があります。リアルタイムなデータの反映が必要な場合は、別途APIやJavaScriptを活用する必要があります。

初心者向きではない

JAMstackは従来のWeb開発とは異なるアプローチを取っているため、初心者にとっては学習コストが高い場合があります。クライアントサイドでの処理やビルドツールの使用など、新たなスキルセットが必要となります。

ページの生成に時間がかかってしまう

JAMstackでは、事前に静的なファイルを生成する必要があります。そのため、ページ数が多い場合やコンテンツの更新頻度が高い場合には、生成に時間がかかる可能性があります。

以上がJAMstackの概要とそのメリット・デメリットです。JAMstackの採用はWeb開発において新たな選択肢を提供していますが、状況に応じて利用する際の利点と制約を理解することが重要です。

JAMstack構成には多くのメリットがありますが、デメリットも存在します。特に外部データの更新が反映されるためには再ビルドが必要という点が課題です。この問題の本質は、HTMLを生成するためにはローカルのPCなどの環境が必要であり、外部データを取得してHTMLを生成する必要があるということです。しかし、開発者が毎回手動でHTMLを生成すると、更新のタイミングを柔軟にコントロールすることができません。

この問題を解決するために利用できるのがCIツール（継続的インテグレーション）です。具体的には、GitやCMSから操作しやすいGithub Actionsを使用しました。図のように、機能開発や改修のパターン、CMSの更新のパターンなどにおいて、Github Actionsを介してビルド＆デプロイを自動化することで、JAMstackの課題の一部を解決しました。さらに、Github Actionsのタスクを使用して、デプロイが完了した際にはチャットで通知する仕組みも導入しました。

ここからはNuxt.jsの簡単な紹介や、メリット・デメリットを解説していきます。

Nuxt.jsとは

Nuxt.jsは、Vue.jsをベースにしたJavaScriptフレームワークで、公式ライブラリを含む強力な開発ツールがバンドルされています。同様のフレームワークにはReactベースのNext.jsなどもあります。

メリットデメリット

Nuxt.jsのメリットは、状態管理ライブラリがデフォルトでインストールされ、フォルダ構造が適切に作成されることです。また、基本的には自動的にルーティングが生成されるため、ファイルを作成しコーディングを進めると自然に完成していきます。

Vue.jsベースなので、状態管理や機能の書き方についてもほぼルール化されています。テンプレートの書き方も、Vue用の属性をHTMLに記述していく形式なので、複数人での作業では主にロジックの共有が容易になります。ただし、この点に関してはReactでも同様のルールと熟練度によって解決できる場合もあります。

一方、デメリットとしては、ReactベースのNext.jsなどと比較して、コードのシンプルさが劣ると感じるかもしれません。また、ルールが存在するため、いくつかの実装では冗長になる場合もあります。しかし、次のバージョンではこれらの改善も予定されています。

個人的な意見としては、熟練したチームでコーディングルールなどが浸透している場合はReactベースのNext.jsがおすすめです。一方、初めて取り組む際にはルールを設けたいがハードルは低くしたい場合にはNuxt.jsが適しています。

Nuxt.jsを用いる場合に気を付けるべき代表的なポイントを2つ紹介します。

最初からNuxt.jsではじめる

フロントエンドの開発では、「静的テンプレートの作成」と「Nuxt.jsへの組み込み」の役割を分担して進めました。初めは慣れや速さを重視して、ejsベースのテンプレートで静的な部分を作成しました。最初の段階でコンポーネントを意識しておくと、後でNuxt.jsに組み込む際に各パーツを簡単に分割できます。

ただし、実際には単に表示させるだけの領域も分割してしまったり、無駄な作業が発生したりすることもありました。JavaScriptに関しても、UIの動作に関連する部分やボタンを押したときのメニュー表示、ハンバーガーメニュー、スクロール量に応じた表示非表示など、Nuxt.jsにそのまま適用できない部分や非同期遷移を考慮できていない部分がありました。

可能であれば、振る舞いや見た目の部分からNuxt.jsをベースに作業を進めると、変換作業や再実装の手間が減り、コードの意図も読みやすくなり、作業者間での確認もしやすくなり、工数も最小限に抑えられると思います。

ジェネレートを考慮

動的なルーティングを行いたい場合、デフォルトの設定ではHTMLが自動生成されません。そのため、あらかじめAPIからURLのリストを取得したり（もしくは自分でJSONなどを準備したり）、それを元にすべてのページを生成したりする必要があります。

また、ジェネレートには以下のような大きな懸念もあります。ジェネレートのタイミングですべてのHTMLが生成されるため、ページ数が増えると時間がかかる可能性があります。ただし、Nuxtのバージョン2.13以降では動的ルーティングを自動的に検出し、ジェネレートの速度も改善されました。現在の状況では、200〜300ページ程度でも運用できますが、ページ数が1000〜2000に増えると時間がかかります。

継続的な運用を行うためには、コンテンツごとにシステムを分けたり、更新されたページのデータだけでHTMLを生成したり、独自のスクリプトを使用して生成したHTMLを追加配置する必要があります。最初から運用を見越して構築することは容易ではありませんが、一度プロトタイプを作成して試してみることをおすすめします。

ここでは、Firebaseの解説や気を付けるポイントを紹介します。

サーバーレスって？

今回サーバーはGoogleのサービスでもあるサーバーレスのFirebaseを選択しました。
サーバーレスを簡単にいいますと、サーバーが常に起動してるわけではなく、必要に応じて起動し、単機能を実装して起動させることができるクラウドのアーキテクチャになります。

しかし今回はStaging環境では認証などの機能を利用してはいますが、Production環境ではその単機能さえ不要であり、ホスティング部分のみを使用しています。

レンタルサーバーやVPSの様にアクセスの集中があるとサーバーがパンクするということもなく、JAMstackにおいては有効なホスティングかと思います。

こういったサーバーレスのサービスはFirebaseの他にもAWSやAzureやIBM等でもありますし、GCP（Google Cloud Platform）でも可能です。
また静的ホスティングだけで考えた場合にはNetlifyやVercelやGithub Pagesといったサービスも利用できます。

気をつけるポイント

今回はStaging環境で認証機能をつけたりと単純に静的ホスティングだけが目的ではなかったのと、GCPへのスケールがしやすくかつ会社としても利用しているサービスの方が好ましかったのでFirebaseを選択しました。

しかしFirebaseは手軽に利用できる反面いくつかの問題点もありました。
例えばキャッシュコントロールが静的ホスティングではできなかったり、
Functionsの機能に対する無料プランの期限があったりなどで思っていたよりもすぐに制限に引っかかってしまいました。

これらはプランを上げたりGCPに移行したりすればもちろん問題ないのですが、場合によっては別のサービスの方がうまくいくこともあるので、利用したい機能がどのくらいのことを行う必要があるのかということを念頭に選択した方が良いです。

今回、HeadlessCMSを用いた開発を行いました。HeadlessCMSの特徴は以下の通りです。

HeadlessCMSとは

冒頭でも簡単に説明しましたが、HeadlessCMSとは、フロント部分がなくAPIが作れるCMSという感じです。
WordPressやMovableTypeなどと同じように管理画面があり、そこではAPIの設定なども行えますし、記事データの入力もできます。

そしてプレビューやデプロイなどの設定もWebhookとして設定することが可能であり、
外部やフロントへの接続部分がすべてコラボレーション前提で作られています。

microCMS

今回は国産サービスでもあるmicroCMSを使用しました。
このUIや説明がすべて日本語という安心感もあるのですが、外部と接続するWebhookがGithub Actionsへ簡単に連携できたり、チャットの通知なども簡単に行うことができたりしたため選びました。

また、その他のHeadlessCMSのサービスは無料枠では記事数に上限があったため、どれくらいのデータ数になるのかという部分で不安でもあったんですが、microCMSは登録数も取得量も無制限というのも安心できる部分です。

API構造

しかし今回はRDBなどであれば簡単に出力できるデータがHeadlessCMSでは取得することができず、フロント側でAPIのデータを元に算出するような実装になってしまった部分がありました。
サイトの仕様によってはAPI構造の自由度やRDBのようなリレーションをさせる部分のロジックなどが必要になる場合があるため、CMS選びは慎重に行った方が良いです。

また、microCMSはREST API形式でしたが、サービスによってはGraphQLが扱えたりするものもあり、データ自体を最適化できるようにも構築できると思いますので、そういった点も比較検討した方が良いと言えます。

 更新者のUXに注意

CMS選択で決め手になる部分としては更新のしやすさなどもあると思います。
microCMSは日本語のUIでスマートなUIなので見た目的なUXは高いですが、
エディタの機能なども重要です。

今回、構築終盤になってエディタの機能が足りないという話になり、どうにか実装できる方法をCMSの設定などで模索するという状態になってしまいました。

そういった視点で他のサービスを見てみると、高機能なものや、入力がスムーズに行いやすいなど、料金の比較だけでは見えない違いがあります。
一つのメリットにとらわれずに様々な視点で行うことで、開発者も更新者も良いUXのCMSを選ぶことができると思います。

まずはリリースができましたので一段落ではあるのですが、改善するポイントなどが色々ありますし、機能追加なども行う予定です。
そういった継続してサイトを見ていく、ということもクライアントワーク同様に行っていきたいと思います。
クライアントワークで今回のようなサイトを構築する場合には、制作期間という部分で多少コストが高くなりやすいのですが、今回構築するにあたって得た知識やコツなどをフィードバックし、より効率的にクオリティの高いものを作っていけるようにしたいと思っています。

デパート採用情報

株式会社デパートでは一緒に働く仲間を募集しています