GraphQLとは？
普段から使われているREST APIは、はじめて定義されたのは2000年でした。
そうなんですよ。もう26年も経ったのです。あの時のWeb開発者にとっては革命だったのですが、２０００年というドットコムバブル時代における技術的なしばりからうまれた原則という側面もあり、現代のスピードが求められる開発スタイルに向いていないのではないかと。
まず、REST APIにはいくつかの代表的な弱点があります。
① 必要以上のデータを取得してしまう（Over-fetching）
② 必要なデータが1回のリクエストで揃わず、複数回APIを呼び出す必要がある（Under-fetching）
③ フロントエンドの画面ごとにAPIを最適化する必要がある
④ APIのバージョン管理（v1、v2など）が複雑になりやすい
例えば、必要に応じて何回もエンドポイントをたたく必要があり、
投稿、コメント欄とユーザーのデータを同時に取得しようとしたら 「/posts」、「/comments」、「/users」といった複数のAPIを同時に取得しないといけなくて処理が煩雑になってしまいます。あるいは、投稿日時データだけを取得したくても余計なデータも返ってくるということも挙げられます。
なぜこうなるかというと、クライアント側が必要に応じてクエリを投げることが基本的に不可能だからです。
こうした課題を解決するために、2015年にFacebook（現Meta）が一般公開したのがGraphQLです。
GraphQLは、クライアント側から必要なデータを事前に指定することができるため、
「/graphql」という一つのAPIエンドポイントで完結できるし、応答時間、処理時間とデータ通信容量も軽減できます。
GraphQLの考え方
本来のREST APIのHTTPメソッドをベースにして説明します。
| 操作 | REST API（HTTPメソッド） | GraphQL |
|---|---|---|
| データ取得 | GET | Query |
| データ作成 | POST | Mutation |
| データ更新 | PUT（全体更新） / PATCH（部分更新） | Mutation |
| データ削除 | DELETE | Mutation |
| エンドポイント | 操作ごとに複数のURL（/users、/postsなど） |
基本的に1つのエンドポイント（例：/graphql） |
| 必要なデータの指定 | サーバー側が返すデータを決定 | クライアントが必要なフィールドを指定 |
| データ取得 | 必要以上・不足するデータになりやすい | 必要なデータだけ取得できる |
| APIバージョン |
v1、v2などが増えやすい |
スキーマの拡張で対応しやすい |
| REST API | GraphQL |
|---|---|
| 「何をしたいか」をHTTPメソッドで伝える | 「何が欲しいか」をクエリで伝える |
GET /users/1 |
query { user(id: 1) { name email } } |
POST /users |
mutation { createUser(...) { id } } |
PUT /users/1 |
mutation { updateUser(...) { name } } |
DELETE /users/1 |
mutation { deleteUser(id: 1) { success } } |
まとめ
簡単にまとめると、GraphQLを学習することにあたり
① Query
→ ほしいデータを予め指定して取得する
② Mutation
→サーバー側にあるデータを追加・変更
③ Subscription
→WebSocketsみたいなリアルタイム処理が可能
次回はJisho API（日本語の辞書API）のGraphQL wrapperを実装して体験記を書いていきたいと思いますので、お楽しみにして頂ければ嬉しいです！