GraphQL Gatewayはフロントエンド開発を幸せにする

はじめに

マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。
弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。

マイクロサービスとフロントエンド

マイクロサービスを採用する場合、フロントエンド（ウェブアプリケーション、モバイルアプリケーションなど）は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API（REST、gRPCなど）を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。

API Gateway

API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチャや分散システムの文脈でよく用いられます。フロントエンドはAPI Gatewayにリクエストを送信し、API Gatewayは適切なマイクロサービスへのルーティング、認証、レート制限、キャッシングなどの機能を提供します。

API Gatewayを利用することのメリット：

• システム全体のセキュリティを中央で管理できます。
• マイクロサービスの内部構造や詳細をクライアントから隠蔽できます。
• クライアントとのインターフェースを統一し、開発・運用を効率化できます。

しかし、API Gatewayも単一障害点となる可能性があり、適切な冗長化やスケーリングの策が必要です。
クラウドプロバイダ（AWSのAPI Gateway、AzureのAPI Managementなど）やオープンソースソリューション（Kong, Tykなど）でAPI Gatewayの機能を実現できます。

BFF (Backend For Frontend)

BFF (Backend For Frontend) は、特定のフロントエンドのニーズに合わせて設計されたバックエンドのパターンです。この概念は、このアプローチでは、各フロントエンド（モバイル、デスクトップ、ウェブなど）が独自のBFFを持つことができ、これによりフロントエンドの要件や性能に最適化されたAPIを提供することができます。

BFFの主なメリット：

• フロントエンドに特化: 各フロントエンド（例: モバイルアプリ、ウェブアプリ、デスクトップアプリなど）のために、専用のバックエンドサービス（BFF）が作成されます。これにより、特定のフロントエンドの要件やニーズに合わせたAPIが提供されます。
• APIの簡略化: フロントエンドが必要とするデータや形式に合わせてAPIを設計・最適化することで、フロントエンドの開発効率やパフォーマンスが向上します。BFFは、裏側で複数のマイクロサービスと連携することで、必要なデータを統合・取得します。これにより、フロントエンドは複数のサービスと直接通信する代わりに、BFFを通してデータにアクセスします。
• 独立性: あるフロントエンドの要件変更が、他のフロントエンドのBFFに影響を与えることはありません。これにより、各フロントエンドチームが独立して動作し、効率的に開発を進めることができます。

BFFのデメリットとしては、フロントエンドの数や種類が増えると、BFFの数も増えることから、管理や運用が複雑になる可能性があります。しかし、それぞれのフロントエンドのニーズに応じて最適化されたAPIを提供することのメリットが、このデメリットを上回る場合も多いです。

またBFFはGraphQL技術とも相性が良いです。GraphQLを使用することで、フロントエンドが必要とするデータを柔軟かつ型安全に取得できます。

GraphQLとTypeScript

GraphQLとTypeScriptは、強い型のシステムを持っているため、連携すると非常に強力です。GraphQLのスキーマからTypeScriptの型定義を自動生成することで、フロントエンドとバックエンドの間での型の不整合やエラーを効率的に減少させることができます。

graphql-codegenというツールは、GraphQLのスキーマやクエリからTypeScriptの型定義を生成することで、APIのレスポンスやリクエストに関しての型の安全性を保証できます。

https://the-guild.dev/graphql/codegen

GraphQL Gateway

GraphQL Gatewayは、複数のサービスを統合し、シングルエンドポイントとしてGraphQL APIをクライアントに提供します。

主なGraphQL Gatewayのライブラリとして、Graphql Meshがあります。さまざまなAPIソース（REST、gRPC、SQLなど）を統合し、それらを一つのGraphQLスキーマに変換します。

https://the-guild.dev/graphql/mesh

GraphQL Federation

GraphQL Gatewayの中でも、複数のGraphQLサービスを一つの統一されたGraphQL APIに組み合わせるためのアプローチがGraphQL Federationです。

GraphQL Federation実現する手法として、次の2つが挙げられます。

• GraphQL Stitching

https://the-guild.dev/graphql/stitching

• Apollo Federation

https://www.apollographql.com/docs/federation/

両者の違いについては、以下の記事に詳しくまとめられていました。
https://zenn.dev/yuta_ura/articles/compare-schema-stitching-and-apollo-federation

まとめ

開発で採用しているマイクロサービス（正確にはモジュラモノリス）アーキテクチャは基本的にバックエンドのアプローチですが、増え続けるサービス/エンドポイントに対してうまく集約してあげることで、フロントエンドでも複雑さを抑えながら効率的に開発を進めることができます。