GraphQLとは
- Facebookが開発
- APIのためのクエリ言語
- APIのリクエストのデータ形式とレスポンスのデータ形式が似ているため、ユーザーフレンドリー
- RESTはアーキテクチャ（設計）であり、GraphQLは言語（DSL）である
REST APIとGraphQLの比較
REST APIのAPI形式
エンドポイントに対して、HTTP動詞でリクエストを投げる
curl https://api.bmf-tech.com/v1/configs
[
{
"id": 1,
"name": "title",
"alias_name": "Title",
"value": "bmf-tech",
"created_at": "2017-09-25 23:08:23",
"value": "bmf-tech",
"deleted_at": null
}
]
GraphQLのAPI形式
単一のエンドポイントに対し、クエリを投げる
curl https://api.bmf-tech.com/api
configs {
id,
name,
alias_name
value,
created_at,
updated_at,
deleted_at
}
[
{
"id": 1,
"name": "title",
"alias_name": "Title",
"value": "bmf-tech",
"created_at": "2017-09-25 23:08:23",
"value": "bmf-tech",
"deleted_at": null
}
]
| REST API | GraphQL | |
|---|---|---|
| エンドポイント | 複数 | 単一 |
| HTTP動詞 | 依存している | 依存していない |
| 型システム | 無し | 有り |
| バージョニングの必要 | 有り | 無し |
| ドキュメントの必要性 | 有り | 無し |
| リソース制限 | コール回数が主 | リソース量に応じて対応 |
-
単一エンドポイントに対して欲しいデータを柔軟に指定
- RESTはエンドポイントごとにレスポンスデータが決まっている。
- GraphQLは単一エンドポイントに対して欲しいデータを指定してレスポンスデータを得る。
-
リソース制限には工夫が必要
- リソース量に応じて対応
- オブジェクトの数をベースにするなど負荷計算の方法を考える必要がある
-
ドキュメントの必要性がほぼない
- API定義がそのままドキュメント代わりになる
- クエリの構造とレスポンスのデータ構造がほぼ同じ
- API定義がそのままドキュメント代わりになる
気になった点
-
ライブラリ依存になる
- クエリのパースをするためのライブラリが必要
-
必ずしもREST APIよりパフォーマンスがよくなるわけではなさそう
- リクエストの回数が減る
- 一回のデータ量が増える
- REST APIでもGraphQLでもデータ量をコントロールする工夫などが必要（ページングとかフィールド指定とか）
-
モニタリング
- REST APIはエンドポイントごとにモニタリングできる
- GraphQLは単一エンドポイントなので、クエリごとにレスポンス性能を監視しずらい。何らかの対応が必要。
- エコシステムの充実を待つか、自前実装
-
キャッシュ周り
- HTTPキャッシュが使えない
- その他色々調べておいたほうが良さそう
所感
- コンポーネントが沢山あって複雑なUIを備えたアプリケーションにおいて、リクエスト数が増えてクライアント側が辛い、というようなシチュエーションなら導入するメリットはありそう。
- Rubelで使ってみようかと考えていたが、時期尚早感があるのでやめる。というか現時点では不要である。
