『複数 API を1つに統合』する2つのアプローチ
マイクロサービス時代に複数 API を1つの GraphQL に統合する手法として Federation と Mesh が確立しました。本記事では編集部の視点で、深掘りした比較を公開情報をもとに整理します。GraphQL 実践 もご参考に。
Apollo Federation
(1) Gateway + Subgraphs。(2) @key で entity 共有。(3) 各 Subgraph が独立。(4) Schema Registry：Apollo Studio。(5) Federation 2 が現行(公開情報をもとに)。
GraphQL Mesh
(1) 多様なソース対応：REST/SOAP/gRPC/DB。(2) The Guild メンテ。(3) plugins で拡張。(4) handler/transformsでカスタマイズ。(5) レガシー統合に強い。
BFF パターンとの比較
(1) BFF：シンプル・特定UI 専用。(2) Federation：複数チーム独立・大規模。(3) Mesh：多様なソース統合。(4) Hot Chocolate Banana Cake Pop：.NET。(5) 選択基準：規模と多様性。マイクロサービス設計 もご参考に。
Federation の実装
(1) 各 Subgraph で @key。(2) Apollo Router：Rust 製。(3) schema check：CI で破壊変更検知。(4) persisted queries。(5) observability：分散トレーシング。分散トレーシング もご参考に。
Mesh の実装
(1) handler 設定：openapi/graphql/odata 等。(2) transforms：filter/rename/encapsulate。(3) cache：レスポンスキャッシュ。(4) authentication：複数ソース統合。(5) runtime：HTTP/CLI/SDK。
運用面の考慮
(1) レイテンシ追加：5〜30ms。(2) SPOF リスク：Gateway HA。(3) 監視必須：subgraph 別レスポンス。(4) スキーマ進化のガバナンス。(5) セキュリティ：認証認可の集約。
採用判断
(1) マイクロサービス数 10超：Federation 検討。(2) レガシー混在：Mesh。(3) 独立チーム多：Federation。(4) シンプル要件：BFF。(5) 段階導入が現実的。API Gateway 実践 もご参考に。
失敗しがちなパターン
(1) Gateway が肥大化。(2) schema 破壊変更：全 client 影響。(3) 監視不足。(4) レイテンシ無視。(5) 過剰な抽象化。対策は、(1)責任分離、(2)CI チェック、(3)分散トレーシング、(4)パフォーマンステスト、(5)KISS、です。