GraphQL vs REST

REST APIはリソースを固定URLで公開するため、ユーザーデータ、そのユーザーの投稿、さらにその投稿へのコメントを必要とする画面では、GET /users/42、GET /users/42/posts、GET /posts/7/comments という3つのHTTPリクエストを順番に発行しなければならない。各レスポンスにはサーバーが定義する全フィールドが含まれ、クライアントが必要とするのは3〜4フィールドに過ぎないにもかかわらず、1オブジェクトあたり一般に10〜20フィールドが返される。このオーバーフェッチはモバイルネットワーク上で累積的な問題となり、ウォーターフォール構造（各リクエストが前のレスポンスを待つ）により、4G回線では一般に1ホップあたり50〜150 msのレイテンシが加算される。

GraphQLはこれら3つのリクエストを、必要なフィールドを厳密に指定した型付きクエリを含む単一のPOST /graphqlにまとめる。サーバーのリゾルバ層はクエリを並列にデータソースへ展開し、単一の整形されたJSONレスポンスを返す。トレードオフとして、POSTボディはデフォルトでキャッシュされないため、Automatic Persisted Queries（APQ）を使わない限りHTTP GETキャッシュ（CDNおよびブラウザ）が適用されない。N+1問題はクライアント側（複数回のフェッチ）からサーバー側（アイテムごとのリゾルバ呼び出し）に移り、FacebookのDataLoaderのようなバッチ処理ツール（N個の個別DBクエリを1つのIN句クエリにまとめる）で解決する必要がある。型イントロスペクション、強力なスキーマ契約、グラフ関係の表現力は、多数のコンシューマーサーフェスを持つプロダクトチームにとってGraphQLを魅力的にするが、シンプルなRESTにはないスキーマガバナンスのオーバーヘッドをもたらす。