corpusctl対WordPress：何を得て、何を手放すか
ヘッドレスWordPressは、ページレンダラーにAPIを後付けで取り付けたものです。移行の正直な論拠、実際のコスト、そしてWordPressにとどまるべき3つのもっともな理由を解説します。
ほとんどのWordPressサイトは、WordPressのままでいるべきです。
これは修辞的な前振りではありません。WordPressがウェブのばく大なシェアを支えているのは、無料で、拡張可能で、どの競合も太刀打ちできない人材層に支えられているからです。1つのチームが1つのサイトを編集し、テーマが必要なことをこなし、トラフィックが安定しているなら——移行は何カ月ものコストをかけ、得られるものはごくわずかです。
この記事は、それが当てはまらなくなるケースについてのものです。
ヘッドレスWordPressは後付けの改造であり、それがにじみ出ている
WordPressはコンテンツをREST APIやWPGraphQL経由で公開でき、多くのチームがこれをうまく運用しています。しかし、自分が何を動かしているのかを正確に把握しておく価値があります。
WordPressの中核的な仕事は、ページをレンダリングすることです。データベースを問い合わせ、テーマを走らせ、フックを発火させ、HTMLを返します。ヘッドレス化するということは、その仕組みをそのまま残し、リクエストごとに起動させたうえで、その出力を捨て、別途組み立てたJSONレスポンスを採用するということです。
結局、1つのプロセスの中で2つのシステムを運用することになります。管理画面はページレンダラーです。APIはページレンダラーの上に載った層です。プラグイン——それこそがあなたがWordPressを選んだ理由です——はページレンダラー向けに書かれており、エディターにフィールドを追加するプラグインが、必ずしもそれをAPIに追加してくれるとは限りません。
corpusctlはページを一切レンダリングしません。テーマ層もテンプレート階層もなく、考慮すべきフックの順序もありません。読み取りクライアントが後付けではなく、主要なインターフェースです。
誰かがあなたの記事を読むとき、実際に何が起きるか
WordPress： リクエストがPHPに届き、PHPがMySQLを問い合わせ、プラグインが走り、テーマがレンダリングします。そのうえでキャッシュプラグインを前段に置き、さらにその前段にCDNを置くこともあり、そしてキャッシュの無効化に実際の時間を費やすことになります——ページは計算されるものであり、キャッシュはいつ変わるとも知れない計算結果のコピーだからです。
corpusctl： 公開するとビルドパイプラインが走ります。コンテンツは検証され、レンダリングされ、オブジェクトストレージ内の不変でハッシュアドレス指定されたファイルに書き込まれ、マニフェストが更新されます。訪問者のクライアントは、スラッグをローカルでマニフェストのシャードへと解決し、そのアドレスをnginxのエッジキャッシュから取得します。
アドレスがコンテンツのハッシュであるため、同じアドレスが異なるコンテンツを返すことは決してありません——だからこそ、無効化戦略なしに30日間キャッシュできます。公開は新しいアドレスを書き出します。パージすべきものは何もありません。