概要
GraphQLは、APIのためのクエリ言語であり、クライアントが必要なデータを必要な形で取得できる仕組みである。本記事では、GraphQLの仕組みを採用判断に必要な範囲で整理し、どのような場面で選ぶべきか、どのようなトレードオフがあるかをまとめる。実装の詳細よりも、設計上の意思決定に焦点を当てる。
なお、入門や実例は別記事GraphQLとは？実例で学ぶ完全ガイドを参照してほしい。本記事は採用判断と運用に絞る。
GraphQLの特徴
採用を判断するうえで押さえておきたいのは、次の3点である。
型システムとスキーマ
GraphQLは、スキーマで型を定義する。スキーマがサーバーとクライアントの契約となり、問い合わせ可能なフィールドや戻り値の型が明確になる。
単一エンドポイントとクエリ言語
RESTが複数のエンドポイントを持つのに対し、GraphQLは単一のエンドポイントにクエリを送る。クライアントは、欲しいフィールドをクエリで指定する。
オーバーフェッチとアンダーフェッチの解消
RESTでは、エンドポイントが返すデータは固定である。そのため、不要なデータまで取得する「オーバーフェッチ」や、何度も呼び出す「アンダーフェッチ」が起きやすい。GraphQLは、必要なフィールドだけを1回のクエリで取得できる。
操作には3種類ある。
- Query（データ取得）
- Mutation（データ更新）
- Subscription（サーバーからの継続的な通知）
向いている場面・向かない場面
向いている場面
- 多様なクライアントが存在する場合。Webやモバイルで必要なデータが異なるとき、各クライアントがクエリで調整できる
- 複数のデータソースを集約するBFF（Backend for Frontend）。フロントエンド向けに最適化した1つのAPIにまとめられる
- 画面ごとに必要なデータが大きく変わる場合。オーバーフェッチを避けたいときに効く
向かない場面
- 単純なCRUDのみのAPI。RESTで十分なことが多く、GraphQLの複雑さが見合わない
- ファイル転送や単純なリソース取得。HTTPの仕組みに素直なRESTのほうが扱いやすい
- HTTPキャッシュを最大限に活かしたい場合。GraphQLは単一エンドポイントへのPOSTが基本で、URLベースのキャッシュが効きにくい
トレードオフ
採用の判断材料として、利点と難点を対にして整理する。
| 観点 | 利点 | 難点 |
|---|---|---|
| 取得 | 必要なデータだけを1回で取得できる | クエリ次第でサーバー負荷が読みにくい |
| 契約 | スキーマが型付きの契約になる | スキーマ設計と進化の運用が要る |
| 窓口 | 単一エンドポイントに集約できる | HTTPキャッシュが効きにくい |
| 性能 | 往復回数を減らせる | N+1問題が起きやすい |
運用の勘所
採用後に効いてくる運用上の論点を挙げる。
- N+1問題: ネストしたフィールドの解決でデータソースへの問い合わせが増えやすい。DataLoaderなどでまとめて取得し、回数を抑える
- クエリのコスト制御: 深いネストや大きなクエリはサーバーに負荷をかける。クエリの深さ制限やコスト計算、タイムアウトを設ける
- 永続化クエリ: 任意のクエリを許すと負荷やセキュリティの懸念がある。あらかじめ登録したクエリのみ許可する運用も検討する
- 認可: フィールド単位のアクセス制御が必要になる。スキーマと認可の設計を揃える
- スキーマ管理: 複数チームで運用する場合、スキーマの統合や破壊的変更の管理ルールを決める
RESTやgRPCとの使い分け
- REST: 公開API、単純なCRUD、HTTPキャッシュを重視する場面に向く
- GraphQL: 多様なクライアント、データの集約、画面ごとに異なる取得要件がある場面に向く
- gRPC: 内部のサービス間通信、低レイテンシ、ストリーミング、多言語の契約共有に向く
これらは排他ではない。外部公開はGraphQLやREST、内部はgRPCというように使い分ける構成もある。
まとめ
GraphQLの採用判断は、次の問いに集約できる。
- クライアントによって必要なデータが大きく異なるか。異なるならGraphQLが活きる
- 複数のデータソースを1つのAPIに集約したいか
- N+1やキャッシュ、クエリコスト制御といった運用を負担できるか
多様なクライアントへ柔軟にデータを返したいなら、GraphQLは強力な選択肢である。一方で、単純なAPIやキャッシュ重視の場面では、RESTのほうが素直である。要件と運用体制に照らして選ぶことが重要である。
