GraphQL とは
GraphQLとはAPI用のクエリ言語である。
フレームワークや特定の技術を指すのではなく、データに対するクエリ言語の仕様
Web版SQL = GraphQL
RESTと何が違う？
REST
RESTfulなAPIはURLとmethodでリソースを表現する
GraphQL
単一エンドポイント。欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエスト
メリット
1. リソースをまとめることができる
RESTではURLがひとつのリソースを表すため、複数のリソースが必要な複雑な画面では複数回のAPIリクエストが必要になる。
結果的に、綺麗に設計されたRESTful APIほど複数回のリクエストが必要になり、パフォーマンスが落ちたりコードの複雑さが増す欠点があった。
GraphQLでは必要なリソースだけを明示的に記載してリクエストし、必要なリソースを無駄なく1発で取得可能。
2. 中間層としても活躍する
マイクロサービスのGateway（中間層）としても良筋と思われる。
スキーマを定義することでGraphQLに対応しているデータソースを取得することができる。
DBを直接取得することもできるし、既存のREST APIを内部的に叩いて取得させることもできる。
REST APIと勝手が違うところ
リソース制限の視点
APIに利用制限を設ける場合、RESTでは1時間にx回マデなどの回数ベースの制限を設ける例がよくあるが、
GraphQLは引っ張るリソース数(=負荷)はクライアントが任意に決められるため、負荷の計算方法を考える必要がある。
githubのGraphQL API v4は、なめるオブジェクトの数をscoreにし、それを1時間に超えない範囲でリクエスト可能にしている。
キャッシュ効率
GraphQLは単一エンドポイントなので、HTTPのCache-ControllのようなURLベースのキャッシュ機構やCDNでのキャッシュはそのままでは使えない。
キャッシュが使えないわけではなくサーバー、CDN、クライアントの各層でキャッシングの現実的な実装は用意されているので
別途必要なものを実装しなければならない。
エラーハンドリング
RESTではエラーはHTTPのステータスコードで表現される
GraphQLではリクエストが通れば200で返し、何かエラーが発生した時はエラーオブジェクトに表現される。
まとめ
- 様々なデータソースを扱えるのでGood
- Web版SQLが発行できてイイネ！
- REST API開発でAPIが多すぎてメンテナンスがしんどいということはGraphQLではなくなりそう。
- リソース制限やキャッシュ効率、エラーハンドリングの仕方などREST APIとはまた異なるノウハウが必要
これからの主流になっていく(らしい)ので、頑張って習得したい。
参照URL