Serverless Operations, inc

>_cd /blog/id_s2ts1zn87zx

title

GraphQLとRest APIの違い

summary

GraphQLは、APIのためのデータクエリ言語で、RESTの代替技術として2015年にMeta Platforms, Inc(旧Facebook)によって公開されました。

GraphQLの特徴は、型付き言語の標準仕様を持ち、クライアントとサーバー間の通信を効率化できることです。一方で、RESTは依然として広く採用されている標準的なAPI技術です。長年にわたり確立された技術であり、多くの開発者や企業に使われ続けています。GraphQLが発表されてから10年近く立ちましたが、現時点ではRESTほどの普及率はないといえるでしょう。では、どういった点でGraphQLとRESTはメリット、またはデメリットがあり、どういった基準で技術選定をされるべきなのでしょうか。

RESTとは?

RESTは、APIの設計において広く使われている手法で、HTTPメソッドリソースで構成されています。

RESTでは、すべてのデータや操作は「リソース」と呼ばれる複数のURLエンドポイントに集約されます。これらのエンドポイントに対して、GETPOSTPUTDELETEなどのHTTPメソッドを使って操作を行う仕組みです。

例えば、/user/1 というエンドポイントがあったとします。この場合、GETメソッドを使ってリクエストを送ると、IDが1のユーザーデータが返ってきます。まさに、URL(エンドポイント)とHTTPメソッドを組み合わせて、必要なリソースにアクセスするという設計です。

RESTの基本は「リソースをどのように扱うか」を決めることです。これがAPIの柔軟性と分かりやすさを生み出しています。

GraphQLとは?

GraphQLは、強力な型システムとスキーマを使ってデータを定義できるデータクエリ言語です。GraphQLのクエリ言語を使えば、リクエスト時に必要なフィールドだけを指定して、無駄のないデータ取得が可能です。これにより、クライアント側は本当に必要な情報だけを受け取ることができ、余分なデータ転送を回避できます。

API開発者は、GraphQLの仕様に基づいてスキーマを定義し、それに従ってクライアントがリクエストを送ります。例えば、ブログシステムを開発することを考えてみましょう。この場合、必要なデータには、ブログ記事、著者、投稿に対するコメントなどがあります。もし、著者のリスト、それぞれのブログ投稿、その投稿に対するコメントを取得したい場合、GraphQLでは以下のようなクエリを記述できます。

{
  users{
    id
    name
    posts{
      title
      comments{
        text
      }
    }
  }
}

このクエリを実行すると以下のようなレスポンスが返ってきます。

{
  "data": {
    "users": [
      {
        "id": "445a794b-fc99-47fe-871b-1f18e76ceb98",
        "name": "Sarah",
        "posts": [
          {
            "title": "Programming Music",
            "comments": [
              {
                "text": "Could not agree more!"
              }
            ]
          }
        ]
      },
      {
        "id": "6cc1ef0d-5a05-4c38-84ee-b0926ddb977b",
        "name": "Michael",
        "posts": []
      }
    ]
  }
}

このようにGraphQLでは1つのクエリで必要なデータを必要なだけ取得することができます。

一方、RESTを使ってこのようなネストされたデータ構造を取得しようとすると、複数のエンドポイントに対して何度もリクエストを送らなければなりません。これが、特にデータ構造が複雑なアプリケーションでは、手間と時間のかかる作業となります。

その点、GraphQLは1回のリクエストで関連するデータを一括取得できるため、効率的なデータ取得が可能です。

GraphQLのメリットとデメリット

では、具体的にGraphQLにはどういったメリットとデメリットが有るのでしょうか。GraphQLを採用するかどうかは、開発するアプリケーションの規模やチームのスキルに依存します。ここでは、それらについて詳しく見ていきましょう。

メリット

  1. エンドポイントは1つだけ
    GraphQLでは、クライアントアプリケーションが呼び出すエンドポイントが1つで済むため、複数のAPIエンドポイントを管理する煩わしさがありません。これは、開発者にとっても運用においても大きな利点です。
  2. 厳格なデータ型とスキーマによる一貫性
    GraphQLはデータ型とスキーマを厳密に定義できるため、クライアントとサーバー間でのデータの整合性が保たれます。これにより、開発者が安心してデータをやり取りできる環境が整います。
  3. フロントエンド開発の効率化
    クエリで必要なデータだけを取得できるため、フロントエンドの開発スピードが向上します。無駄なデータを扱う必要がないため、コードの効率化にも繋がります。
  4. 自動生成ドキュメントが簡単に
    クライアントは、利用可能なデータ型のリストを簡単にリクエストできるため、APIドキュメントを自動生成するのに最適です。これにより、ドキュメントの管理がシンプルになります。

デメリット

  1. 学習コストが高い
    RESTに比べてGraphQLの学習曲線はやや急です。チームにGraphQLの経験が少ない場合、導入には時間がかかる可能性があります。
  2. サーバーサイドの負担増加
    データの処理が主にサーバー側で行われるため、サーバーサイド開発者にとっては、より複雑な実装が求められることがあります。特に大規模なアプリケーションでは、負担が大きくなることもあります。
  3. キャッシングが難しい
    RESTに比べて、GraphQLではキャッシングの実装が複雑です。RESTのようにエンドポイント単位でキャッシュが容易ではないため、工夫が必要です。
  4. ファイルを扱うのが難しい
    GraphQLの仕様にはファイルを扱うための標準仕様がありません。Base64エンコードを行うことで実装は可能ですが、それなりに負荷の高い非効率な処理となります

RESTのメリットとデメリット

さらにRESTについてのメリットとデメリットも整理します

メリット

  1. シンプルで使いやすい
    REST APIはHTTPプロトコルに基づいており、GET、POST、PUT、DELETEなどの標準的なメソッドを使うため、理解しやすく、実装が容易です。
  2. プラットフォームに依存しない
    RESTはHTTPを介して動作するため、クライアントとサーバーが異なる技術スタックを使っていても問題なく連携できます。異なるプラットフォーム間の通信を容易にします。
  3. ステートレス
    RESTはステートレス(状態を保持しない)なため、各リクエストが独立して処理されます。これにより、スケーラビリティが高く、分散システムでもパフォーマンスが維持されやすくなります。
  4. キャッシュ可能
    HTTPプロトコルの一部として、REST APIのレスポンスはクライアントやネットワーク層でキャッシュが可能です。これにより、パフォーマンスの向上が期待できます。
  5. 広く普及している
    REST APIは、モバイルアプリケーションやWebサービス、IoTデバイスなど、多くの分野で利用されています。そのため、多くのドキュメントやサポートが存在します。

デメリット

  1. ステートフルな処理に向かない
    RESTはステートレスであるため、クライアントの状態をサーバー側で保持する必要があるシナリオ(セッション管理や連続的なトランザクション処理など)には適していません。
  2. リソースの過剰取得/不足取得
    RESTでは、必要なデータが一度に大量に送信されることもあれば、必要なデータが細分化されて何度もリクエストを送信する必要がある場合もあります。これにより、帯域幅の浪費やパフォーマンス低下が発生することがあります。
  3. 標準化の曖昧さ
    REST APIは一貫した実装方法を提供するわけではなく、設計の自由度が高いため、APIごとに設計や命名規則が異なる場合があります。その結果、異なるAPIを利用する際の学習コストが発生する可能性があります。

RESTとGraphQLのどちらを選ぶべきか

GraphQLは確かにRESTのオーバーフェッチの課題を解決しているとは言えますが、それがクリティカルな課題になることも限られた条件下であると言うことも出来そうです。GraphQLを採用しているmetaやGitHubのような企業では大量のトラフィックがあるため、データのフェッチが一回で済むことでサーバー側の負荷やクライアントとサーバ間の通信量は大きく下がるでしょう。また、大量のトラフィックをアプリやWebなどの様々なクライアントとやり取りしてるようなユースケースだと効果はありそうです。そういった状況下に無い場合は、学習コストが低くより広く使われているRESTを選定するチームや企業が多いのではないかなというのが個人的な見解です。

また、開発生産性の観点から考えるとTypeScriptを使い慣れているチームは型システムの相性からGraphQLで進めたほうが効率がいいかもしれません。GraphQL Code Generatorなどを使うことでGraphQLのスキーマ定義からフロントエンドの型定義を自動生成して開発を進めることが出来ます。このあたりは開発チームの好みや思想によってくる部分が大きいでしょう

Written by
CEO

堀家 隆宏

Takahiro Horike

  • Facebook->
  • X->
  • GitHub->

Share

Facebook->X->
Back
to list
<-