GraphQL Federation とマイクロサービス

GraphQL Federation とは

マイクロサービスでAPIが供給されているとして、異なるマイクロサービスが複数あるときに、まるでテーブル結合するかのように、マージしてくれるもの。
クエリーだけじゃなくて、更新系もうまいこと、処理してくれる。

主要なプロダクト

Apollo Federation と WunderGraph Cosmo、GraphQL Fusion などがある。
Apollo が GraphQL Federation のデファクトスタンダートで一番導入実績があり、WunderGraph Cosmoは、最近の導入実績が急激に増えているものらしい。
Apolloは、有料版じゃないと使えない機能があったりするが、Cosmoは、全機能が利用可能で、且つ、Apolloと互換性のあるI/F仕様になっているという安心感が、その理由のようだ。
さらに、Cosmo は AWS Lambda 用に最適化されたコンポーネントがありサーバーレス化が可能なので、小規模なサービスには、持ってこいである。

マイクロサービスアーキテクチャとの親和性

マイクロサービスでは、サービスを超えてDBを共有することはせずに、専用のDBで設計する。
会員管理はRDBを使い、予約管理は DynamoDBを使うということも可能になる。

GraphQL Federation を使って、複数サービスをマージするとして、1つ1つのマイクロサービスは、小さくてシンプルなので、開発しやすい。
その一方で、フロンエンドの実装は、やや、面倒そうではある。

自社プロジェクトでの検証

自社プロダクトである「貸会議室予約管理システム」は、当初は、モノリシックに構築しようと思ったが、マイクロサービス化を推し進めることにした。
懸念されることは、マイクロサービスとして切り出したり、マイクロサービス間の整合性に頭を使わないといけないので、生産性が低下しそうなこと。
だが、それ以上に、マイクロサービスでシステムを構成することのノウハウは、AI時代だからこそ財産になると思うので、学びを優先することにした。

貸会議室の予約管理システムをマイクロサービスにすると、ユーザー管理、会員管理、リソース管理、予約管理、各種通知、・・・、単純に考えても、これだけのマイクロサービスが切り出せる。
これは、再利用できるアセットのバリエーションが増えるということでもある。
モノリシックに作り込んでしまうと、「貸会議室予約管理システム」がたった1つのアセットなので、例えば、「営業支援システム」のような開発をするときにも、「貸会議室予約管理システム」からユーザー管理機能だけを抜き出すのが面倒で、またもや「営業支援システム」用のユーザー管理機能を作り込んでしまう。ほとんど同じなのに。
それが、マイクロサービスになっていると、ユーザー管理マイクロサービスがDockerコンテナで動く状態なので、ユーザー管理機能を新たに作るという動機は起こらず、そのまま再利用する流れになる。

システムを細かくマイクロサービスで設計するときの切り札となるのが、複数サービスの Federation なので、まずは、WunderGraph Cosmo で開発を進めながら、同時に検証してみようと思う。最終的に、やっぱり Apollo に落ち着いたということになるかもしれないが。