バートリーのさいとうです。
今回は
【ヘッドレスCMS】でHPを作ろうとしたら、知らない言葉がたくさん出てきたので、それぞれの意味とか役割を調べてみた
というテーマで、最近僕の中でホットなこの話題について、調べたらわからないことがたくさんあったので、そのまとめをしていこうと思います。
最近友人のポートフォリオ的なHPを作りたいという要望に応えるために、いろいろやり方を検索していたところ、ヘッドレスCMSが良さそう、という結論に辿り着いたのですが、
じゃあ、インフラとかアーキテクチャとかどうなっているんだろう…
と思って調べてみるとエンジニア歴1年未満の僕にはまだまだわからないことだらけ。笑
ですので、今回はヘッドレスCMSや、その周りの用語や仕組みについて、なるべく噛み砕いて解説しようと思います。
僕のように
ポートフォリオやHP等の環境構築をしたいが基本的な知識がない…
という方は、この記事を最後まで読んでいただけるとその全貌が見えてくるかと思います。
- ヘッドレスCMSでアーキテクチャを組むときの構造の全体像と、頻繁に出てくる主要な用語を理解できることで、他の記事が読みやすくなる
- ヘッドレスCMSとは何かを知ることができる
- CMSとヘッドレスCMSのメリット・デメリットを比較することができる
- アーキテクチャ（環境構成）の全貌を理解できる
今回構築しようとしている仕組みの全貌
先に、今回構築しようとしている仕組みの全貌をお見せします。
何が何だか、という感じだと思うので、それぞれ詳細についてお伝えしていきます。
CMSについて
まず初めに、CMSとヘッドレスCMSについて簡単にメリットデメリットの比較をしてみたいと思います。
CMSとは
CMSとは、Content Management Systemの略称です。
代表的なCMSはお馴染みのWordPress（以下WP）ですね。
WP環境では、投稿記事の管理はもちろん、WP内でページレイアウトの修正も可能です。
（ちなみにこのブログもWPで構築されています。ページを表示するためにコードは書いていません。）
ヘッドレスCMSとは
対して、ヘッドレスCMSは、CMSの見た目が用意されていないver.です。提供しているのは、コンテンツ（記事等）を管理するための仕組みです。
ヘッド = 見た目
レス = ない
ヘッドレス = 見た目が存在しない、つまりいわゆるユーザーから見える部分が用意されていません。ですので、自分で描画する必要があります。
その分、自由に好きな言語でページを描画できます。
また、コンテンツ管理とページ描画が分離していることで、ページ読み込み速度が向上する、保守性が高くなるなどのメリットもあります。
代表的なヘッドレスCMSとしては
などがあります。より詳細に知りたい、という方はこちらの記事等を参照ください。
CMSとヘッドレスCMSの比較
CMSとヘッドレスCMSについて、上記の内容を一度まとめると
- WordPressのような、環境を用意するだけでコンテンツ（記事）の管理も見た目の描画も全部担ってくれる仕組み
- 見た目は用意されているので、自分で描画する必要はない
- コンテンツを管理するのに特化した仕組み
- ユーザーから見える部分 = ページは自分で作成する必要がある
- ページを作る自由度が高く、処理速度も高速になる
また、メリット・デメリットをまとめると以下のようになります。
| コンテンツ管理 | ページを表示するまでの手間 | ページの読み込み速度 | ページレイアウトの自由度 | |
| CMS | ◯ | ◯ | △（プラグイン等があると重くなる） | △（強制的に書き換えも可能） |
| ヘッドレスCMS | ◯ | ×（その分自由が効く） | ◯ | ◯ |
以上のまとめから、
- サクッとブログやHPを作りたい方はCMS
- 見た目にこだわりたい、ポートフォリオとして構築したい、処理速度を高速にしたい、JSでヌルヌル動かしたいという方はヘッドレスCMS
を選ぶと良いと思います。今回は、ポートフォリオとしての機能を持たせたい、APIを叩きたい、拘ってデザインしたい、などの条件があるので、ヘッドレスCMSを選択することにしました。
ちなみに、ヘッドレスCMS
ただし、これだけでは環境は構築できず、その周囲に色々便利な仕組みが存在します。
周囲の仕組み
ここまで、ヘッドレスCMSを解説してきましたが、今回の要件ではヘッドレスCMSを採用するときに、大きく分けて、二つの仕組みが必要になることがわかりました。
- フロントエンドの描画（ページの描画）をする開発言語（フレームワーク）
- 静的サイトホスティングサービス
それぞれについて、解説していきます。
フロントエンドの描画をする開発言語（フレームワーク）
まずは、先ほどもヘッドレスCMSの項で説明したように、自分でページは描画しないといけないことから、その開発用言語が必要になります。
Vue.jsやNuxt.jsなど、選択する言語・フレームワークは自由ですが、ヘッドレスCMSとの関係性には注意が必要です。具体的には、APIを取得する仕組みが必要になります。
ヘッドレスCMSはコンテンツ管理を行うと説明しましたが、例えば記事のデータが保存されているとすると、そのデータはAPIと呼ばれる仕組みで取得することが可能です。
APIは、ざっくりいうと、データだけのまとまりです。
実際、今読んでいただいているこのページに表示している記事のタイトル・本文というのは、「データ x ページの描画」で構築されていますよね。
イメージとしては、この組み合わせを、WPは自動的にいい感じにしてくれますが、ヘッドレスCMSだとそれを自分でやる必要がある、という感じです。
まぁ難しいことはよくわからんが、とにかくヘッドレスCMSを使いたいんや！という方はVue.jsやNuxt.jsといったフレームワークを利用することをお勧めします。（とはいっても、書き方等は学習する必要がありますので悪しからず。）
静的サイトホスティングサービス
次に、静的サイトホスティングサービスです。
これは、静的サイトを実際にサイトを公開する仕組みのことで、静的サイトとは、ユーザーのリクエストに必ず同じページを返すものです。
この代表例としては、こちらの記事にまとまっているので参照いただければと思いますが
- Netlify
- GithubPages
などがあります。
特に、Gitと連携して、masterマージされたらビルドからデプロイまでやってくれる仕組みを提供してくれるNetlifyはかなり良さそうだなと思っています。
取り上げた仕組みを利用したアーキテクチャ
そして、特にJavaScript x ヘッドレスCMS x マークダウンを利用して構築するアーキテクチャを、Jamstackと言います。
J = JavaScript = Vue.jsやNuxt.js
A = API = ヘッドレスCMS
M = Markdown
の頭文字をとって、Jamstackです。stackは積み重ねみたいな意味があります。
今回は、このアーキテクチャでポートフォリオ型HPを開発していこうと考えています。
webhookについて
少し本筋からは外れるかもしれませんが、webhookという仕組みにも触れておきます。
ざっくりまとめると、アプリケーションAのPOSTリクエストを飛ばした際に、そのリクエストを利用してあれこれしようぜ！という仕組みです。
アプリケーションAをGitとした時の例を見ていきましょう。
具体的には、先ほど取り上げた静的ホスティングサービスのNetlifyは、Git上のリポジトリへのコミット・プッシュ（ここでPOSTリクエストが送られる）をフックに設定して、それを検知したら本番環境にビルド→デプロイを行うという設定が可能です。
本来であれば、開発中のブランチ→マスターにマージ→手動でデプロイというのがデフォルトの流れになるので、webhookという仕組みを利用することで、デプロイを自動化することが可能になります。
詳細や実際の様子については、こちらの記事をご覧ください。
全体像の再掲
最後に、全体像を再掲します。
まとめ
今回は、【ヘッドレスCMS】でHPを作ろうとしたら、知らない言葉がたくさん出てきたので、それぞれの意味とか役割を調べてみたというテーマで、最近僕の中でホットな話題を取り上げました。
やはり何かを作るって、楽しいですね。
このブログは、月に15本を目標に、実務から学んだプログラミングのあれこれを発信しています。
誰かのためになれば、嬉しいです。
最後まで読んでいただき、ありがとうございました。
それでは。
参考
・2021年版 話題のヘッドレスCMS10選
・静的 Web サイトホスティングサービス比較
・Netlifyで静的サイトのホスティングをする
