Edited at

RESTの次のパラダイムはGraphQLか

More than 1 year has passed since last update.


GraphQL概要

ざっくり言うと、従来のAPIのように設計したフォーマットのレスポンスを返すようにサーバーを実装するのではなく、

クライアント側で必要な情報をクエリとして定義し、サーバーはそのクエリに応じたレスポンスを返すシステム。

例えば、従来のREST通りにユーザー一覧を取得しようとした場合、クライアントが

GET /users.json

を発行すると


response

{

"users": [
{
"id": 1,
"name": "hoge",
"email": "hoge@example.com"
},
{
"id": 1,
"name": "foo",
"email": "foo@example.com"
}
]
}

のようなレスポンスが返ってきますが、同じことをGraphQLで実行する場合、

{

users {
id
name
email
}
}

のようなクエリをクライアントが発行することになります。

なぜこのようなシステムが必要かの説明の前に、RESTの問題点を挙げてみます。


RESTの問題点


Server Side Renderingの場合


  • コントローラでEager Loading等のクエリ最適化を意識しないといけない

  • ビューを実装するときも結局裏側でどのようなクエリが発生するかを意識しないといけない


Client Side Renderingの場合


  • コンポーネント毎に必要な情報をリクエストする場合、AJAXリクエストを何度も発行する必要がある

  • 提供されているAPIが不十分だと、クライアント側でテーブル結合が必要となる


共通する問題


  • クライアント毎にちょっとずつ違うAPIを用意してメンテしないといけない


    • 端末に応じて異なるサイズの画像を返す

    • ネイティブアプリとウェブアプリで異なる結果を返す

    • 等など



  • APIに「暗黙的な契約」が発生し、APIを変更するコストが大きくなる

  • APIが最大公約数として設計され、必要以上の情報をやりとりしやすくなる


GraphQLのメリット


  • クライアント毎に必要な情報を個別のクエリとしてリクエストできる

  • 一度の通信で済む

  • 並列化しやすい

  • JSON APIよりも可読性が高く、拡張しやすい

このように、クライアント自身が必要な情報を定義することでRESTが抱えていた様々の問題が解決します。

「APIを設計する」こと自体がほとんどなくなる時代がきたらおもしろいですね。


参考URL