この記事は Movable Type Advent Calendar 2022 の5日目の記事です。
毎年も結婚記念日投稿を2018年〜はじめて4年目です。
今年は実装周りのネタがほとんどなくMTの設計を試行錯誤しながらな一年でした。
Movable TypeのData APIでJamstackできるのでは？ということでやってきたわけですが、やってみた感想だったりをこの記事で紹介したいと思います。
Movable TypeのJamstackの問題点
去年からJamstackでMovable Typeを運用していくつかの課題が出てきました。
Data APIでビルドを走らせると管理画面が機能しなくなる
Movable TypeのData APIを利用するとビルド時にかなりの負荷がかかります。
MTクラウドでもそこそこなスペックで運用してても、モノリポ構成でビルドが走るため複数の箇所でDataAPIを走らせていることによる管理画面アクセスが重たい問題があります。
昔、MT再構築中は管理画面が全く機能しなくなる思い出が過りました。
1コンテンツデータの1アプリケーションだった場合は、そこまで気にしないのですが色々なデータを取り扱う大規模なサイトではData APIでJamstackは厳しいという感じでした。
Data API のレスポンス（1記事）で 12秒ほどかかります。
これはほかのheadless CMSよりもレスポンスは遅いと思います。
スペックを上げることで一時的に解決できるかもしれませんが、現実的ではありません。
コード側である程度ビルドを早くする方法はありますが、根本の問題もあります。（記事が多すぎてビルドのタイムアウトでコケたりなど）
そのため、Jamstackで行う場合は一覧系は静的JSONつくって運用するのがベターという感じです。
詳細記事に管理しても、Data APIで返さずに id で取得できるプラグインみたいなものを別立てで作るほうがいいかもしれません。
Data API v5について
先月、Movable Type 8の秋リリース予定という告知がありました。
段階的に 機能はMovable Type 7にも機能は追加されてるようです。
Data API v5 は r.5201 で実装済みみたいですね。
OpenAPI JSON Schema にはすでに対応済 (r.5201)
個人的にうれしいのは、 OpenAPI JSON Schema になったということですね。
v4までは、自前でスキーマを作って管理し Swagger UI で展開していました。
v5が出たタイミングで Data APIのドキュメントも変わりました。
新しいドキュメントは、Redocly で管理しているようです。
このドキュメントで、直感的に見やすくなったこととOpenAPIの形でJSONが吐き出してるという点です。
これにより、自前で用意せずにスキーマを入手できるようになったので、個人的に嬉しいところでした。
この v5で少しでもレスポンスが改善されると良いのですが現時点で v4とv5ではあまり差が出ないのかなと思っています。
現状のアプリケーションをv4をv5に変更することで、改善されるかが今後の課題です。
v4のレスポンス結果
v5のレスポンス結果
何回か連続した処理結果としては、あまり変化がない感じを受けました。
実際のレスポンス実行を繰り返すと早いときと遅いときがあるという感じです。
記事が少ない場合はあまり感じないのですが、記事が数千記事になるとビルド時間が1時間以上かかることもおきます。
AWSなど他のツールなどでビルドを行う場合、ビルド時間のMAXタイムが制限があったりするため、記事が多いサイトなどはMovable TypeでJamstackするのは難しいと思いました。
また、運用者が複数人いる場合のケースはJamstackを採用するのは難しいと経験しました。
複数人で運用した場合、ビルドのタイミングも同タイミングで行う場合があり、AさんとBさんが同時にビルドした場合、どちらかビルドが終わるまで次のビルドが走らないという問題と例えば30分かかるビルドがプラスで30分ビルドが走るため、その期間はMTクラウドはまったく動かなくなります。
- Aさんビルド開始：30分
- Bさんビルド開始：Aさんのビルドが終わってから開始30分
- Bさんが完了
↑この一時間はMTクラウド自体が重たくなっている状態
データ更新中に別の担当者がビルドを開始すると、データ更新中の担当者が管理画面が重たくなるという問題は頻発します。
APIとして提供する場合は、やはり管理画面に影響されないような形が望ましいのかなと個人的に思っています。
ビルドに限らずフロントエンドでAPIを利用することはやはり多いので、負荷が多いとサイト運用者が負担になるためビルドやAPIのアクセスに左右されないような形になってほしいと思いました。
docker-mt-lamp Release/2.2 リリース
Jamstackの案件で利用するためのツールも強化しました。
主にData APIをフロントエンドでも利用しやすい取り組みを行いました。
私が開発環境として使ってるdocker-mt-lamp環境もアップデートしました。
今回のアップデートは、起動シェルやドキュメント更新とSwagger UIやSwagger EditorやRedoclyを組み込みました。
Swagger UIでは、スキーマ情報から実際のローカル環境や開発環境・本番環境でエンドポイントのレスポンスを確認できる点です。
Postman や Pawなどのアプリを使うことで確認はできます。
しかし、独自に拡張したパラメータなどは公式ドキュメントにはないため、Swaggerにいれておくと良いと思いローカル環境に追加しました。
ローカルでもRedoclyで参照できるようにしました。
手元で参照できるようにしています。
data_api.sh というシェルスクリプトを追加しました。
これにより都度JSONをダウンロードせずに手元の環境に落として参照できます。
# Data API ドキュメント
wget https://raw.githubusercontent.com/movabletype/mt-docs-data-api-reference/master/src/openapi/v5.json -O /images/i.json
Swagger Editorも同梱するようにしました。
この方法で、公式から取得したJSONをYamlに変換してSwagger UIで展開できるようにしました。
Movable TypeでJamstackできるのか。
Movable TypeでJamstackはできます。
しかし、いくつか導入するためにはかなり注意するポイントが多いです。
Data APIがレスポンスが安定しないという点や記事が多い場合そもそもビルドが制限時間で終わらない場合などがあります。
また複数人で運用する大規模なサイト（いつビルドされたのかやビルドが単純に時間がかかる）には向いていないこともわかりました。
結果として静的なJSONを吐き出して運用するしかありません。
これらを踏まえてJamstackをMTで利用するべきかという点では、規模や運用人数やビルド負荷なども考慮した上で採用するべきだと感じました。
まとめ
まだまだMovable TypeでJamstackは手探りな状態ですが、来年のMT8に向けてMT7には機能や改善はされるようですので期待や検証しつつ知見を増やしていければなと思っています。
Discussion