背景#
ホームページ上にさまざまな情報を載せるようになると、掲載すべき情報がさまざまな場所に点在するようになる。 それを一つの場所で管理するためには、REST APIやGraphQLなどのCMSとは異なるサービスが必要になる。 REST APIやGraphQLサーバを構築するには、費用がかかる。
費用をゼロに近づけるためには、自分でサービスを運営するか、格安のサービスを探すしかない。 自分で運営するには、運営コストが無視できないし、格安のサービスも昨今の事情からいつ値上がりするかがわからない。
一方で、主に行いたいことは情報の取得のみである。
RESTの GET、GraphQL であれば query のみであり、POSTや mutations は行わなくても問題はない。
GET のみであれば、HTTP サーバにファイルを置いておくだけで REST API として扱えるようになる。
データを JSON で用意しておき、必要な JSON の内容を適切な場所に index.json として配置する。
そのディレクトリをエンドポイントとして公開しておけば、擬似 REST API の完成である。
FauxREST#
擬似REST APIを作成するツールである FauxREST を作成した。 このツールは、与えられたディレクトリ内の JSON ファイルを特定のルールに従って分割し、 所定の場所に置くことで、擬似REST APIのファイルを出力する。 このツールを使って、API を構成し、そのAPIから情報を取得して必要な情報を取得するよう変更すれば、 データと表示を分割できる。
メリット#
- 堅牢である。
- 純粋な HTTP サーバのみで済むため、APサーバに比べて堅牢である。 また、データの更新はサーバ外で行うため、外部からの攻撃もあまり心配する必要がない。
- コスト/メンテナンスフリーである。
- 無料で HTTP サーバを利用できるサービスはいくつかあり、どのサービスも歴史が長い。 また、1つのディレクトリ以下を擬似RESTに対応させれば良いため、 すでに公開しているWebページに追加するコストも高くないと言える。
- 専門のツールである。
- 従来、SSG (Static Site Generator)を用いて、擬似REST APIを構築する方法が取られていた。FauxREST は擬似REST APIを構築する専門のツールであり、できるだけ覚えることが少なくなるよう設計されている。
- 競合として、
static-api-generatorもある。
デメリット#
- 動的なリクエストへの対応に限界がある。
- ページ遷移やフィルタリングについては対応を考えていない。結局のところ、ファイルであるため、ページ遷移が必要なほど大量のデータがある場合は、このツールの対象外であろう。
- 大量ファイル時のファイルシステムのオーバーヘッドが無視できない。
- 数千以上のエンドポイントがある場合は、それに対応する数千以上の細かいファイルが存在することになる。この場合、チェックアウトやデプロイ時に必要になるオーバーヘッドが大きくなることが予想される。
- リアルタイムでの更新は対象外である。
- 元々の出発点が
GETのみで良いから簡易で堅牢な REST API を構成したいということであるため、データの更新は対象外である。擬似 REST API としては利用できるものの、更新も含めた REST API としては動作しない。データの更新は、背後のGitコミットやCI/CDのパイプラインを回すことで、安全なタイミングで行うと割り切っている。
- 元々の出発点が
Pseudo REST API of Myself#
このURLにアクセスすると、エンドポイント一覧が表示される。
それぞれのエンドポイントに GET アクセスすると、JSONファイルが返される。
これが実現することで、以下のようなことが可能になった。
ツールを作成したり更新すると、tamada/api の GitHub Actions に更新のリクエストが飛ぶ。
tamada/api はツールの情報を取得し、REST API を更新する。
続けて、tamada/api は tamada/homebrew-tap や tamada/tamada.github.io への更新のリクエストを飛ばす。
tamada/tamada.github.io は、必要な情報を上記エンドポイントから取得して、ページを更新する。