API・メッセージング

GraphQL ぐらふきゅーえる

APIクエリ言語RESTスキーマフェッチFacebook
GraphQLについて教えて

簡単に言うとこんな感じ!

「必要なデータだけをピンポイントで注文できるAPI」だよ! 普通のAPIだと「定食セット」しか頼めないのに対して、GraphQLは「ご飯だけ・おかずだけ・しかも量はこれくらい」って細かく指定できるイメージなんだ!


GraphQLとは

GraphQL(グラフキューエル)は、Facebookが開発したAPIのためのクエリ言語およびランタイム仕様です。従来のREST APIでは、サーバー側があらかじめ決めたエンドポイント(URLの口)からデータをまとめて受け取るしかありませんでした。GraphQLでは、クライアント(アプリやブラウザ)側が「どのデータをどんな形で欲しいか」を自由に指定できます。

たとえば「ユーザーの名前とアイコンだけ欲しい」「商品情報と在庫数を一度に取りたい」といったリクエストを、単一のエンドポイントに送るだけで実現できます。これにより、無駄なデータの受け取り(オーバーフェッチ)や、データが足りなくて何度もリクエストを送る(アンダーフェッチ)といった問題を解消できます。

スマートフォンアプリやSPA(シングルページアプリケーション)の普及で「通信量を減らしたい」「画面ごとに必要なデータが違う」というニーズが高まり、REST APIの限界を補う技術として急速に広まりました。GitHubやShopify、Twitterなど多くの大手サービスが採用しています。


GraphQLの核心:クエリ・ミューテーション・サブスクリプション

GraphQLには、データのやり取りを行うための3つの操作タイプがあります。

操作タイプ役割REST相当
Query(クエリ)データの取得(読み取り)GET
Mutation(ミューテーション)データの作成・更新・削除POST / PUT / DELETE
Subscription(サブスクリプション)リアルタイムのデータ受信WebSocket

クエリの書き方イメージ

# REST API なら /users/1 と /users/1/posts を2回叩く必要があるところ…
# GraphQL なら1回のリクエストで欲しいものだけ取れる!

query {
  user(id: "1") {
    name        # 名前だけ
    icon        # アイコンだけ
    posts {
      title     # 投稿タイトルだけ
    }
  }
}

スキーマ定義(型定義)

GraphQLではスキーマと呼ばれる「データの設計図」をあらかじめ定義します。これがAPIの仕様書になるため、フロントエンドとバックエンドの開発者が同じ言葉で話せるようになります。

type User {
  id: ID!
  name: String!
  icon: String
  posts: [Post]
}

type Post {
  id: ID!
  title: String!
  body: String
}

歴史と背景

  • 2012年 — Facebook社内でモバイルアプリ向けAPIの非効率さを解決するために開発開始
  • 2015年 — オープンソースとして公開。REST APIの代替として注目を集める
  • 2018年 — GraphQL Foundationが設立され、Facebookから独立したコミュニティ運営へ移行
  • 2020年前後 — GitHub・Shopify・Twitter・Airbnbなどの大手が本番環境で採用を発表し、急速に普及
  • 現在 — フロントエンドフレームワーク(Next.jsNuxt.jsなど)との連携ライブラリも充実し、スタンダードな選択肢のひとつに

GraphQL vs REST API:何が違うの?

GraphQL vs REST API REST API GET /users/1 GET /users/1/posts GET /users/1/followers ⚠ 複数のエンドポイントに  何度もリクエストが必要 ⚠ 不要なデータも一緒に返ってくる  (オーバーフェッチ) vs GraphQL POST /graphql(1つだけ) query { user(id:"1") { name posts { title } } } ✅ 1回のリクエストで完結 ✅ 必要なデータだけ返ってくる ✅ スキーマが仕様書になる  (ドキュメント自動生成も可)

比較まとめ表

比較項目REST APIGraphQL
エンドポイント数機能ごとに複数基本1つ
データ取得の柔軟性サーバー側が決めるクライアントが指定
オーバーフェッチ起きやすい起きにくい
学習コスト低めやや高め
キャッシュのしやすさ◎(URLベース)△(工夫が必要)
向いている用途シンプルなCRUD複雑なデータ要求・モバイル

GraphQLを使うべきか?の判断軸

シンプルなAPIで十分?
├─ YES → REST API で OK
└─ NO
    ├─ 画面ごとに欲しいデータが違う? → GraphQL が有利
    ├─ モバイルで通信量を減らしたい? → GraphQL が有利
    └─ リアルタイム更新が必要?      → Subscription も使える

関連する規格・RFC

規格・仕様内容
GraphQL SpecificationGraphQL Foundation が管理する公式仕様(バージョン管理あり)
RFC 7231REST APIの基盤となるHTTPセマンティクス
OpenAPI (Swagger)REST API向けのスキーマ定義仕様。GraphQLのスキーマに相当

関連用語

  • REST API — URLとHTTPメソッドでリソース操作を行う従来型API設計スタイル
  • API — ソフトウェア同士が機能を呼び出し合うための接続口
  • エンドポイント — APIへのアクセス先となるURL
  • スキーマ — データの構造・型を定義した設計図
  • WebSocket — サーバーとクライアントが双方向通信するプロトコル(Subscriptionで使用)
  • JSON — GraphQLのレスポンスデータが返ってくるデータ形式