普段はRailsを中心にバックエンドの開発を行っておりますが、社内に蓄積された小規模なWebサイトのメンテナンスも時折行うことがあります。この手の小規模サイトにはたいていwordPressが用いられていて、wordPressはそれ自体便利な技術であることは認めるものの、その裏側をきちんと把握しないことには非常に扱いにくく、ちょっとした編集にも苦労させられる場面が多くありました。そんな折、この手の小規模サイト構築の手法としてJAMstackというアーキテクチャが広がっていると知りました。どんなものかと試したところ、wordPressに代わる小規模開発手法になりうるだけでなく、今後のフロントエンド開発の大きなトレンドになるものだろうと納得いたしました。
本記事では前編と後編とに分けて
- wordPressの何が問題となるのか？(前編)
- JAMstackのアプローチとメリット・デメリット
について解説していきます。
前編では自分がWordPressの運用をしていて課題に感じた点についてまとめ、後編でJAMstackがそれらの課題にどうアプローチしているか、およびそのメリットデメリットについてまとめています。
ちなみに本ブログもJAMstack構成で構築しております。wordPressとJAMstackを実際に触れてみて感じたことをまとめておりますので、特にWordPressの運用に課題を感じているWeb開発者の方は是非ご覧ください！
JAMstackとは(再訪)
公式サイトより引用。
Jamstack is an architecture designed to make the web faster, more secure, and easier to scale. (略) The core principles of pre-rendering, and decoupling, enable sites and applications to be delivered with greater confidence and resilience than ever before.
プリレンダリングとデカップリングというふたつの原則の元、Webサイトをより早く、よりセキュアに、より簡単にスケールできるアーキテクチャとのこと。これでは「なるほどわからん」という感じですが、まずはJAMとは何かについてみていきます。
JAMは
- Javascript
- APIs
- Markup
の頭文字を表しています。先ほどの原則にのっとって説明するならば、
ブログの各記事や記事一覧ページのHTMLファイルはすでに構築されており(prerendering), 動的な処理が必要な場合はブラウザでjavascriptファイルを実行する際か、あるいはWebサイトをビルドする際にAPIを利用することで、バックエンドの処理をアウトソースすること(decouoling)で構成されます。
といえるかと思います。公式ページにも以下の一文がありました。
Now we can outsource things like authentication and identity, payments, content management, data services, search, and much more.
(公式サイトより)
JAMstackは特定の技術を指すわけではなく、上記の原則にのっとった新しいweb開発のアーキテクチャです。そのため、WordPressとは直接比較できるものではないのですが、従来のCMSを代表するWordPressに対して、新しいWeb開発の潮流であるJAMstackという考え方が、どのように現れ、影響を与えているのかを理解する上でわかりやすい対比になるのではないかと考えております。
JAMstackで用いられる主要な技術について触れていきます。
JAMstackを支える技術
JAMstackは特定の技術を指す言葉ではなく、上記の原則にのっとった新しいweb開発のアーキテクチャです。以下、JAMstackで用いられる主要な技術について触れていきます。
静的サイトジェネレータ
Static Site Generetor、SSGと略されているのも見かけます。コンテンツの追加の際にWebサイトを事前にビルドし、静的な状態で配信できる技術です。すなわち、記事の一覧や詳細ページ、指定したタグの記事一覧などの全ページを開発段階でHTMLファイルとして生成(prerendering)することで静的なWebサイトを構築し、あたかも動的処理がなされているかのようなページ遷移をする静的サイトを配信することができます。
それでは実際に記事を追加する際はやはり開発者の手が必要なのか？となりますが、そこについては後述するヘッドレスCMSが解決します。
SSGの有名なものにReact製のGatsby, GO製のHugoなどがあげられます。自分がReactの勉強に着手しているため、自身のブログをカスタマイズする際にReactの勉強になればと、本ブログはGatsbyで構築しております。(最近ではReact製フレームワークのNext.jsでもSSGができるとのことで、気になってはいるのですが、着手するのはもう少し先になりそうです…フロントエンドのトレンドは本当に早いですね。)
CDN
コンテンツデリバリネットワーク。世界中に分散して配置されたエッジサーバーと呼ばれるWebサーバーのグループのことで、高速化、高耐久性を実現できます。ユーザーがリクエストする際に、ユーザーから最も距離的に近いエッジサーバーからデータを返すことで高速化を実現、仮にどこかのサーバーがダウンしても他のサーバーが稼働しているので耐久性を保持できます。なによりサーバーの管理はクラウドでいい感じにやってくれるので、管理の手間もかかりません。従来の動的サイトのようにサーバーサイドの処理も走らないので、DDoSなどの集中アクセス攻撃の対策にも効果があるとされています。[参考]
さらに、個人利用の規模なら無料で利用できます。いいことづくめです。いますぐレンタルサーバーから乗り換えましょう.。
CDNの例としては、CEOが”JAMstack”の言葉を提唱したNetlifyや、AWSのCloudfrontなどもこれに当たります。まだ実際に試してはいませんが、AWSの場合はS3と組み合わせてS3 + Cloudfrontの構成でWebサイト構築、運用ができそうです。本ブログではNetlifyを採用しております。
ヘッドレスCMS
SSGとCDNだけでもWebサイト構築はできますが、先述したようにこれでは開発者のみ運用可能なものとなり、運用者にやさしくありません。ユーザーに優しいインターフェースとしてのCMSがほしくなりますが、SSGそのものには動的な処理が含まれません。そこで、記事の管理のみを担当し、ビルド時に記事の情報をAPI経由で渡すことでコンテンツ管理を行う手法が確立されています。それがヘッドレスCMS（Headless CMS）と呼ばれるものです。
ヘッドレスとは、描画部分に責を負わないことに由来します。コンテンツの管理と描画の責務を分割(decoupling)することで、同じコンテンツでも描画する場所や手段を自由に選択できます。
代表的なものとしてはNetlifyCMSやContentful、日本でもmicroCMSというサービスが開発されている模様です。本ブログではまずお試しとしてNetlifyCMSを導入しています。
まとめ：JAMstackでDXは爆上がり
Netlifyを用いた場合ですが、NetlifyCIを接続することでgithubのmasterブランチにpushして自動でビルド、デプロイを行う設定をかなり簡潔に行うことができ、良質な開発体験を素早く実現できます。