Pseudo-Rest-Api

🗣️ 背景 # 色々な CLI アプリケーションを作っている。十数個ある。そのリリース作業で、ずっと以下の3つに困っていた。 1. 1回のリリースで触る場所が多い。 昨今の CLI アプリケーションは、バイナリを置いて終わりではない。macOS と Linux、arm64 と amd64 の組み合わせでバイナリを用意し、コンテナイメージを公開し、crates.io などのレジストリに登録し、Homebrew🍺 のレシピを更新し、プロダクトのホームページも作る。1回のリリースに対して、公開先がいくつもある。 2. 同じ情報を何箇所にも手で書き写していた。 バージョン、リリース日、説明、ライセンス。同じ内容を、プロダクトのリポジトリ、Homebrew のレシピ、自分のホームページに、それぞれ別々に書いていた。二重、三重の管理である。当然、情報の齟齬が様々なところで生じるし、更新忘れも結構あった。 3. プロダクトの一覧が、機械可読な形でどこにもない。 どんなプロダクトがあるのか、それぞれいつリリースしたのか。ホームページに載せたくても、プログラムから読める形で集約された場所がないので、結局また手で書くことになる。2の原因でもある。 このうち 1 は、後述するように既存のツールでもそれなりに何とかなる。厄介なのは 2 と 3 で、これは第1次情報がどこにあるのかを決めていないことが原因である。裏を返せば、正となる情報を1箇所に決めて、他はすべてそこから取ってくるようにすればよい。 このようなことを自動化したいなと、これまでずっと思っていたのだが、この度、ようやく目処が立ったので、内容をまとめておく。 🌊 Workflow # 最初に行うべきは、マシンリーダブルなものを第１次情報とすることである。これを tamada/api として作成した。そして、プロダクトの情報は基本的に GitHub で管理し、GitHub 上で管理できない情報のみを tamada/api に置くことにした。加えて、GitHub Pagesで、擬似REST APIとして、さまざまな情報を公開することにした。基本的に情報を取得させるだけであるため、GET メソッドのみ対応として、JSON を様々な場所においておくことで対応した。具体的な内容は、https://tamada.github.io/api/ を参照されたい。ホームページの更新や Homebrew なども、すべてこのリポジトリの GitHub Pages から情報を取得することにする。

背景 # ホームページ上にさまざまな情報を載せるようになると、掲載すべき情報がさまざまな場所に点在するようになる。 それを一つの場所で管理するためには、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から情報を取得して必要な情報を取得するよう変更すれば、 データと表示を分割できる。