道玄坂 WordPress Meetup #3でHeadlessCMSについて聞いてきた
メルカリでバックエンドにWordPressをHeadlessCMSとして使い、フロントエンドをNuxt.jsで構築したという事例に基づく話。
WordPressをHeadlessCMSとして使うことに興味があったので行ってみた。
所感
WordPressをHeadlessCMSとして使う場合のメリットやデメリットが整理でき、構築ノウハウなどもある程度掴むことができたので有意義だった。
WordPressの強靱化はCloudFrontを前段に置くのがコスト的に安上がりで早いと思うが、HeadlessCMSとして使って静的サイトにできれば速度はもちろんセキュリティ的にもサイトがより強まるので、かけられるコストや開発体制、目標とするパフォーマンス次第で検討の価値がある選択。
またWordPressのテーマ開発もけっこう学習コストあるので、それを単純なREST APIを使ったウェブサイト開発にできるのはいいかもしれない。
要はテーマ開発の経験がない場合はHeadlessCMSの道を行くのもひとつかもしれない。WordPressの関数はまともなプログラミング経験者にとっては割と悪夢なところあるから・・・慣れればそれほど苦痛ではないけど、慣れる道をプログラマーに勧めていいのかどうか考えてしまう。個人的な意見ですが。
メリットとデメリットの整理
HeadlessCMSのメリットとデメリット
WordPress以外のHeadlessCMSにも共通するもの。
- メリット
- フロントエンドの自由度向上
- 配信対象の拡大（APIを通してウェブサイトに留まらない様々なチャンネルへの配信）
- デメリット
- RESTful APIの知識が必要で学習コスト開発コストが大
- フロントエンドとバックエンドで別々のインフラが必要
- コンテナベースの設計で費用を圧縮するなどの工夫
- フロントエンドとバックエンドでそれぞれセキュリティ検討が必要
HeadlessCMSとしてWordPressを採用するメリット（バックエンド側）
- 既存の資産が使える（管理画面に慣れているユーザーが多い）
- カスタマイズ性が高い（足りない機能があってもなんとかなる）
HeadlessCMSとしてWordPressを使うメリット/デメリット（フロントエンド側）
- メリット
- 自由度が高い
- バックエンド側と独立して開発できる
- 言語はなんでもOK
- デザインの制約が少なくなる
- WordPressでコーディングするための学習コストがなくて済む
- ページが軽量に作れる
- auditsでオールグリーン
- デメリット
- 全て自分で構築する必要がある
- WordPressの再発明に近い
- WordPress側で用意されていないAPIエンドポイントもある
- プレビュー用のAPIは用意されていない => 独自エンドポイントを追加
その他得られた知見
構成
- WordPress
- WordPressをGoogle Kubernetes Engine上でコンテナとして展開
- プレビューは専用のWordPressコンテナを展開（Headlessのため標準のプレビューが使えない
- DBはCloudSQL => コンテナと分離することでコンテナ側をスケーラブルに
- メディアライブラリはCloudStorage => コンテナ上に置かないことでコンテナ側をスケーラブルに
- アクセス制御はCloudArmor
- 監視はStackdriver
- Netlify
- Nuxt.jsをデプロイ
- CircleCIのCI/CDと併用
オススメしたいWordPressプラグイン
- REST API – Filter Fields
- APIのレスポンスに含めたいスキーマを指定できる
- これを使わないと全部の情報が返ってくるのでデータが重いしスピードが遅い
- WP API Menus
- メニューの情報を表示するAPIエンドポイントを追加
- 親子関係もきちんとネストして返してくれる
Netlify
静的サイトを高速配信するためのサービスで、S3+CloudFrontとの違いはJAMStackで言う「アトミックなデプロイ」と「即時キャッシュ無効化」を実現しているところ。
S3はアトミックなデプロイができないし（さらに言うと個々のファイルの全体反映までに数秒のラグもあり）、CloudFrontのキャッシュ無効化も数秒以上のラグがあるが、Netlifyは軽く試した感じそういうことがない。
ほかにもいろいろと高機能。
