Movable Type実装者から見たJamstack・HeadlessCMSという選択

Jamstackとは

「JavaScript・APIs・Markup」の３つの技術から構成されるWebアプリケーションのアーキテクチャです。
簡単に言うと、フロント側でJavaScriptを動かして取得したAPIと合わせて事前に静的ファイルを生成し、その静的ファイルをホスティングサーバーで配信する一連の仕組みです。

HeadlessCMSとは

従来のCMSとは異なり、コンテンツ管理（バックエンド側）の機能のみを提供するCMSです。
見た目の担保はフロント側で行います。一般的にはVueやReact等のフレームワークを用いながらマークアップして見た目を実現することが多いです。

Movable Type特有の記法と複雑なロジックから解放される

複雑な条件分岐や値のフィルタ制御をするロジックを記述しようとすると、どうしても階層が深い条件分岐ロジックを組み込む必要が出てきます。そのため、Movable Typeのテンプレートで複雑なロジックを実現しようとすると、HTMLタグとMovable Typeタグが混ざった視認性の良くないコードになってしまうことがあります。
対して、JamstackとHeadlessCMSの場合、CMS側はコンテンツ管理の役割だけを担保し、APIを発行します。複雑な条件分岐や値のフィルタリングを含んだ表示ロジックは、APIを取得したJavaScript側で実装することが出来ます。そのため、「この条件のときにこの種類の製品だけ表示したい」といった複雑な表示条件になりそうな場合は、Movable TypeではなくHeadlessCMSを選択し、表示ロジックの担保はJamstack側のマークアップで行う方がよいケースがあります。

どのようなサーバー構成・デプロイ環境にするかなどの要件定義がやや複雑になる

Movable Typeの場合は、Cloud版を契約したり、パッケージ版をインストールするLAMPサーバーを用意するだけで環境準備が完了することが多いですが、Jamstack・HeadlessCMSの構成の場合は、まず「どのようなHeadlessCMSを選ぶか、どのようなデプロイ環境にするか」という実装を行う前段階の要件定義から深く検討する必要があります。
「WordPressやMovableTypeみたいにサーバー用意するだけでよいと思ってた」というような認識の齟齬が生じることもありますので、事前の認識すり合わせや要件定義をしっかり行い、これから構築していく環境のイメージを共有します。

よくある構成だと…

• AWS Amplify等を利用して静的サイトをデプロイする
• フロント側のソースコードはGitHubで管理し、Webhookを紐付けて、対象ブランチにマージするなどのイベントがあったら通知させる
• HeadlessCMS側にはWebhookを紐付けておいて、CMSを更新したら更新通知をさせ、再度デプロイする

という構成にすることが多いです。（図1）

Movable TypeもHeadlessCMSのように利用できるか？

「すでにMovable Typeの管理画面UIに慣れているのでCMSは変えたくないが、フロント側は自由度を高めたい」という要望があったと仮定します。
Movable TypeもDataAPIというAPIを配信することが出来るので、Movable TypeはAPI配信のみに利用し、フロント側をJamstack構成にすることは可能です。ただし、SPAでなくJamstack構成の場合、原則SSGとして出力する必要があります。しかし、Movable Type側に記事更新を通知させるようなWebhookの仕組みがないため、Movable Type側に更新通知用ファイルを作り、サーバーでファイル更新を監視して更新があったら通知を飛ばしてデプロイさせる等のひと工夫をする必要はあるでしょう。

---

今回は、Movable TypeとJamstack・HeadlessCMSを比較した上でのメリット・デメリットをご紹介しました。
実際のプロジェクトにおいては、Movable TypeありきHeadlessCMSありきではなく、それぞれのプロジェクトにとってベストな方法をすり合わせ、選定していくことが非常に重要ですので、今回ご紹介したメリット・デメリットも１つの参考として考えて頂けると幸いです。