APIの設計手法として長らく業界の標準であった「REST API」。しかし近年、フロントエンドの高度化に伴い「GraphQL」を採用する企業が増えています。 技術的な話に入る前に、まずは両者の違いを「レストランの注文」に例えて考えてみましょう。
レストランにおけるREST APIの限界
REST APIは、いわば「メニューごとに窓口が違うフードコート」です。
例えば、ハンバーガーセットを頼みたいとします。あなたはまずハンバーガーの窓口（/api/burgers/1）に行き、次にポテトの窓口（/api/sides/potato）に行き、最後にドリンクの窓口（/api/drinks/coke）へ行かなければなりません。
これでは何度も窓口を行き来する手間（複数回のリクエスト）がかかります。さらに、「ハンバーガーのピクルスは抜いてほしい」と思っても、窓口からは必ずピクルス入りの完成品が渡されてしまいます。これが、不必要なデータまで取得してしまう「オーバーフェッチ」と呼ばれる問題です。
GraphQLという究極のオーダーメイド
対するGraphQLは、「非常に有能な専属ウェイター」です。 あなたはウェイターに「ハンバーガー（ピクルス抜き）、ポテトのSサイズ、コーラ」と書いた注文書（クエリ）を一度だけ渡します。するとウェイターは厨房に回り、あなたが指定した通りのものを、一つのトレイにまとめて持ってきてくれます。
これがGraphQLの最大の特徴です。フロントエンド（顧客）側から「どのデータが、どのような形で欲しいか」をピンポイントで指定でき、バックエンドはそれに応じて過不足なくデータを返します。
GraphQLのメリットと導入の壁
この仕組みにより、以下のようなメリットが生まれます。
- 通信量の削減: スマートフォンなどのモバイル環境において、不要なデータを取得しないことはパフォーマンスの劇的な向上に繋がります。
- 柔軟なUI変更: 画面に新しい表示項目を増やしたい場合でも、RESTのように新しいエンドポイントをバックエンド側に作ってもらう必要がなく、フロントのクエリを書き換えるだけで完結します。
一方で、魔法の杖ではありません。 「キャッシュの制御が難しい」「N+1問題が起きやすい」「バックエンドの実装難易度が上がる」といった課題も存在します。単純なブログサイトなどであれば、従来通りREST APIの方が手軽で適していることも多いです。
どちらを選ぶべきか？
一つの画面で様々な種類のリソース（ユーザー情報、投稿、コメント、いいね数など）を複合的に表示するような、複雑なWebアプリケーションを開発するなら、GraphQLは最高の選択肢になり得ます。 自社の「レストラン」がどのような注文を多く受けるのかを見極め、適切なアーキテクチャを選択してください。