GraphQL
クエリ言語とスキーマ言語から成る
クエリ言語
GraphQL API のリクエストのための言語
query, mutation, subscription の３種類に分けられる
query: データ取得系
mutation: データ更新系
subscription: サーバーサイドからのイベント通知
スキーマ言語
GraphQL API の仕様を記述するための言語
リクエストされたクエリは、スキーマ言語で記述したスキーマに従って GraphQL 処理系によって実行され、レスポンスを生成する
code: schema example
type Query {
currentUser: User!
}
type User {
id: ID!
name: String!
}
Query : クエリのために予約された、ルートの型名
currentUser フィールド : null にならない User 型
type User は null にならない ID 型の id フィールドと String 型の name フィールドを持つ
ひとつひとつのフィールドからリゾルバ (resolver) という関数が生えてくる
リゾルバは、オブジェクト (例えば User のインスタンス) を引数として受け取り、そのプロパティ (例えば User#name ) を返すシンプルな関数
code: query example
query GetCurrentUser {
currentUser {
id
name
}
}
これは「このクエリの名前は GetCurrentUser で、タイプは query (データ取得系) で、currentUser の id と name を取得する」という意味になる
これに対応するレスポンスは、例えば次のような JSON データになる
code: response example
{
"data": {
"currentUser": {
"id": "xxxxx",
"name": "foo"
}
}
}
スキーマに定義したフィールドのうち、クエリで指定したフィールドのみが返ってくる
GraphQL の利点
クエリからレスポンスの構造を予測できる
スキーマをもとにしてクエリの記述/発行をサポートしてくれる開発ツールが存在する
GraphiQL (グラフィクル)
クエリを発行してレスポンスを閲覧するためのツール (つまり API コンソール)
スキーマをもとにクエリの補完や API リファレンスとの統合が行われる
学習コストが小さい
クライアントについては自作することもそれほど難しくない(らしい)
GraphQL の欠点
パフォーマンスの分析が難しい
GraphQL 処理系を実装するのが難しい
画像や動画などの大容量バイナリの扱いに向いていない
リクエストやレスポンスのシリアライズ方法は規定されていないが、多くは JSON
JSON はバイナリのシリアライズが苦手