AWS AppSync Merged API でマイクロサービスの GraphQL を統合 - チーム分散開発の実践

Merged API の必要性

マイクロサービスアーキテクチャで複数チームが GraphQL API を開発する場合、フロントエンドは複数のエンドポイントにリクエストを送る必要があり、クライアント側の複雑さが増します。Merged API はこの問題を解決し、複数のソース API を単一のエンドポイントに統合します。ユーザーチームの User API、注文チームの Order API、商品チームの Product API をそれぞれ独立して開発・デプロイしつつ、フロントエンドからは 1 つの GraphQL エンドポイントでアクセスできます。API Gateway のような REST ベースの API 集約と異なり、GraphQL のスキーマレベルで統合されるため、クロスサービスのクエリも単一のリクエストで実行できます。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

ソース API の設計と独立デプロイ

各チームはソース API として独立した AppSync API を開発します。スキーマ、リゾルバー、データソースはソース API ごとに管理され、チームは自分の API を自由にデプロイ・更新できます。ソース API の更新は自動的に Merged API に反映されます。スキーマの競合 (同名の Query フィールド、同名の型定義) はマージ時に検出され、エラーとして報告されます。競合を避けるため、チーム間でスキーマの命名規則を事前に合意し、名前空間的なプレフィックス (user_、order_) を使用するか、共通の型定義を共有スキーマとして管理する設計が推奨されます。

認証戦略

Merged API レベルでデフォルトの認証方式 (Cognito ユーザープール、IAM、API キー、Lambda オーソライザー) を設定します。ソース API ごとに追加の認証方式を設定でき、特定のフィールドに対してソース API の認証を適用できます。例えば、Merged API のデフォルト認証を Cognito に設定しつつ、管理者向けの Mutation にはソース API レベルで IAM 認証を追加する構成が可能です。@aws_auth ディレクティブでフィールドレベルの認証を制御し、特定のフィールドを特定の Cognito グループのみに公開できます。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ

AppSync Merged API は複数チームの GraphQL API を単一エンドポイントに統合するサービスです。各チームの独立したデプロイを維持しつつ、フロントエンドにはシンプルな単一エンドポイントを提供します。マイクロサービスアーキテクチャで GraphQL を採用する場合の標準的なパターンです。