GraphQL

クエリ言語とスキーマ言語から成る

クエリ言語

GraphQL API のリクエストのための言語

query, mutation, subscription の３種類に分けられる

query: データ取得系

mutation: データ更新系

subscription: サーバーサイドからのイベント通知

スキーマ言語

GraphQL API の仕様を記述するための言語

リクエストされたクエリは、スキーマ言語で記述したスキーマに従って GraphQL 処理系によって実行され、レスポンスを生成する

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 ) を返すシンプルな関数

query example

query GetCurrentUser {

currentUser {

id

name

}

}

これは「このクエリの名前は GetCurrentUser で、タイプは query (データ取得系) で、 currentUser の id と name を取得する」という意味になる

これに対応するレスポンスは、例えば次のような JSON データになる

response example

{

"data": {

"currentUser": {

"id": "xxxxx",

"name": "foo"

}

}

}

スキーマに定義したフィールドのうち、クエリで指定したフィールドのみが返ってくる

GraphQL の利点

クエリからレスポンスの構造を予測できる

スキーマをもとにしてクエリの記述/発行をサポートしてくれる開発ツールが存在する

GraphiQL (グラフィクル)

クエリを発行してレスポンスを閲覧するためのツール (つまり API コンソール)

スキーマをもとにクエリの補完や API リファレンスとの統合が行われる

学習コストが小さい

クライアントについては自作することもそれほど難しくない(らしい)

GraphQL の欠点

パフォーマンスの分析が難しい

GraphQL 処理系を実装するのが難しい

画像や動画などの大容量バイナリの扱いに向いていない

リクエストやレスポンスのシリアライズ方法は規定されていないが、多くは JSON

JSON はバイナリのシリアライズが苦手