さいきょうの下駄履きアーキテクチャがRust GraphQLバックエンドだった件
さいきょうの下駄履きアーキテクチャを考えたい
凡人でも成果を出せるような、最もツールから恩恵を受けながら開発できるバックエンドアーキテクチャを考えていきます。
下駄履きアーキテクチャとは
上のツイートを参考に、TypeScriptの静的型付け等の機能・ツールにより 凡人でもなんとかWeb開発を行えるようなアーキテクチャ のことを、本記事では 下駄履きアーキテクチャ と呼ぶことにします。
何を考える必要があるのか
私自身はバックエンドがメインのため、バックエンドで必要な要素について考えていきたいと思います。
色々考える必要はありますが、とりあえず以下は論争になりがちなので、このあたりを考えましょう。
- 静的型付け言語 or 動的型付け言語
- GraphQL or REST API
- マイクロサービスにする？
静的型付け言語 or 動的型付け言語
これは間違いなく 静的型付け言語 です。下駄履きアーキテクチャ考案の元ネタのツイートでも挙げられる最強の下駄の一つです。
IDEだけでなく、AIツール（GitHub copilot）の支援も受けやすいところが凡人に優しいところです。
そのため、PythonやJavaScriptではなく、TypeScript や Go や Rust を使いましょう。Pythonを使う場合はmypyなどの利用を検討すると良さそうです。
GraphQL or REST API
REST APIを使用している場合、Swaggerのyamlファイルを管理することになると思います。このyamlファイルには 「更新されないことがある」「書いてることと実装がなぜか異なる」 という特徴（経験則）があります。
それに対し、GraphQLでは、コードファーストアプローチを取れば、実装と常に一致し、更新されないといったことは起こりえません。そのため GraphQL こそが、下駄履きにふさわしいアプローチでしょう。
最近、少しフロントエンドのタスクをおこなったのですが、graphql-codegenによる型の自動生成による開発体験は最高でした。これも下駄履きにふさわしいと言えます。
もっともこれはSwaggerでもできますが。
バックエンド視点からのGraphQLの利点では以下が参考になると思われます。
マイクロサービスにする？
GraphQLを使用する場合、それをBFFとして、後ろのマイクロサービス群とgRPCなどでやり取りをするマイクロサービスアーキが考えられます。
ただし、マイクロサービスは辛いという話もちらほらあり（参考: GitHubの元CTOが後悔しているらしい）、凡人的には避けたいところです。
以下のツイートを見ると、速い言語を使えばわざわざそれをマイクロサービスに切り出さなくてもモジュールとして持っていけば十分とのことです。
NestJS（TypeScript）やStrawberry（Python）は使わず、Rustを使えば良さそうです。
幸いRustにもjuniperやasync-graphqlといったGraphQLライブラリがあるそうです。
結論
RustでGraphQLを使えば最強に下駄が履ける！
このアーキテクチャは、あの一休でも採用されているそうなので、凡人ではない、優秀な開発者にも有用と言うことがわかります。凡人にも優秀な人にも役立つ最強アーキテクチャですね。
余談
私Rust書いたことないんですが、本当に最強なんですかね。
（追記）
追加で調べ直したらRESTでもコードからyaml作成することは可能みたいです（逆はよく聞くけど、こっちの方向もあるの知らなかった）
- Go, Ruby: OpenAPIを活用したスキーマの自動生成や型安全な開発について紹介
- NestJS: NestJS の @nestjs/swagger でコントローラーから Open API(Swagger) の定義書を生成する
- FastAPI (Python): FastAPIの概要
そう思うと大規模サービスでもない限り、大抵は FastAPI で REST が無難で現実的な気がする。
Discussion