GraphQLとは

bmf-san アプリケーション
#API#HTTP#REST#GraphQL

GraphQLとは

  • Facebookが開発
  • APIのためのクエリ言語
    • APIのリクエストのデータ形式とレスポンスのデータ形式が似ているため、ユーザーフレンドリー
  • RESTはアーキテクチャ（設計）であり、GraphQLは言語（DSL）である

REST APIとGraphQLの比較

REST APIのAPI形式

エンドポイントに対して、HTTP動詞でリクエストを投げる

curl https://api.bmf-tech.com/v1/configs

GraphQLのAPI形式

単一のエンドポイントに対し、クエリを投げる

curl https://api.bmf-tech.com/api

REST API GraphQL
エンドポイント 複数 単一
HTTP動詞 依存している 依存していない
型システム 無し 有り
バージョニングの必要 有り 無し
ドキュメントの必要性 有り 無し
リソース制限 コール回数が主 リソース量に応じて対応

  • 単一エンドポイントに対して欲しいデータを柔軟に指定

    • RESTはエンドポイントごとにレスポンスデータが決まっている。
    • GraphQLは単一エンドポイントに対して欲しいデータを指定してレスポンスデータを得る。

  • リソース制限には工夫が必要

    • リソース量に応じて対応
    • オブジェクトの数をベースにするなど負荷計算の方法を考える必要がある

  • ドキュメントの必要性がほぼない

    • API定義がそのままドキュメント代わりになる
      • クエリの構造とレスポンスのデータ構造がほぼ同じ

気になった点

  • ライブラリ依存になる

    • クエリのパースをするためのライブラリが必要

  • 必ずしもREST APIよりパフォーマンスがよくなるわけではなさそう

    • リクエストの回数が減る
    • 一回のデータ量が増える
    • REST APIでもGraphQLでもデータ量をコントロールする工夫などが必要（ページングとかフィールド指定とか）

  • モニタリング

    • REST APIはエンドポイントごとにモニタリングできる
    • GraphQLは単一エンドポイントなので、クエリごとにレスポンス性能を監視しずらい。何らかの対応が必要。
      • エコシステムの充実を待つか、自前実装

  • キャッシュ周り

    • HTTPキャッシュが使えない
    • その他色々調べておいたほうが良さそう

所感

  • コンポーネントが沢山あって複雑なUIを備えたアプリケーションにおいて、リクエスト数が増えてクライアント側が辛い、というようなシチュエーションなら導入するメリットはありそう。
  • Rubelで使ってみようかと考えていたが、時期尚早感があるのでやめる。というか現時点では不要である。

参考