1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

「学生ひよこ界隈が送るGo/Javaで実現する「はじめてのバックエンド」Advent Calendar 2025」21日目の記事は、GraphQLについてです。

フロントエンドからAPIを叩いていると...

  • ユーザー名だけ表示したいのにAPIから返ってくる情報が多すぎて、必要なデータを探すのが大変...
  • 記事とそのコメント、さらにコメントした人の情報まで表示するには、APIを何回も叩かないといけない...

といったちょっと煩わしいな、と感じることがあるかもしれません。

この記事では、GraphQLとは何なのか、そしてなぜ必要なのか、について概念をざっくり解説します。

  • GraphQLという言葉は聞いたことがあるが、仕組みについてさらに知りたい方
  • REST APIと利点などを比較したい方

GraphQLがどのような問題を解決するための技術で、REST APIと比べてどのようなメリットがあるのかを具体的に理解できるように、頑張りましょう!

REST APIでの課題

GraphQLのメリットを理解するために、普段使われている、いわゆるREST APIが抱える課題をおさらいします。

データの過剰取得

例えば、ブログ記事の一覧ページで、各記事の「タイトル」だけを表示したいのに、/api/postsというエンドポイントは、各記事のcontent(本文)まで含んだ巨大なJSONを返してくるかもしれません。

これは圧倒的に通信量の無駄ですよね...

過少取得とN+1問題

前のケースとは逆に、ある記事ページで「記事本文」と「その記事へのコメント一覧」を表示したい場合、REST APIの設計によっては、例えば以下のように複数のリクエストが必要になることがあります。

  1. GET /api/posts/1 で記事データを取得
  2. GET /api/posts/1/comments でコメント一覧を取得

さらに、各コメントの投稿者名も表示したい場合、コメントの数だけ GET /api/users/{id} を呼び出す必要が出てくるかもしれません。

これがいわゆる「N+1問題」で、ページの表示速度が低下する原因となります。

GraphQLとは?

GraphQLは、これらの問題を解決するために開発された、APIのためのクエリ言語とその実行環境です。

基本的な考え方

RESTが「リソース」ごとに複数のエンドポイント(/users, /postsなど)を持つのに対し、GraphQLは通常、単一のエンドポイント(例: /graphql)しか持ちません。

クライアント(フロントエンド)は、そのエンドポイントに対し、「どのようなデータが、どのような形で欲しいか」などを記述したクエリを送信します。サーバーは、そのクエリを解析し、要求された通りの構造でデータを返します。

クエリの例

例えば、「記事とコメントと投稿者」を一度に取得したい場合、フロントエンドは以下のようなクエリを送信します。

query GetPostDetails {
  post(id: "1") {
    title
    content
    author {
      name
    }
    comments {
      body
      author {
        name
      }
    }
  }
}

サーバーは、この要求通りのJSONを一度の通信で返します。

スキーマの例

バックエンドにおいて、GraphQLサーバーは「提供できるデータとその構造」をスキーマとして定義します。

スキーマは、APIの仕様がそのまま書かれているようなイメージです。

# スキーマ定義言語 (SDL) で記述
type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
  comments: [Comment!]!
}

type User {
  id: ID!
  name: String!
}

type Comment {
  id: ID!
  body: String!
  author: User!
}

# クライアントがデータを取得するためのエントリーポイント
type Query {
  post(id: ID!): Post
}

このスキーマがあるおかげで、フロントエンドは「どのようなデータが取得可能か」を正確に知ることができ、型安全な開発が可能になります。

GraphQLを利用するメリット

  • 必要なデータだけを、必要な形で: 「ユーザー名だけ欲しい」といった場合、必要なデータだけを、必要な構造で取得できるので、無駄な通信が一切発生しません。

  • APIを何回も叩かなくていい: 記事とコメント、コメントした人の情報など、これらを一度のクエリでまとめて取得できるのでリクエスト回数が減り、アプリケーションのパフォーマンスも向上します。

  • 型システム: スキーマが定義されているおかげで、フロントエンド側でTypeScriptの型を自動生成するのも簡単です。APIの仕様変更にも強く、開発体験が大幅に向上します。

おわりに

この記事では、GraphQLについてざっくりと解説しました。

フロントエンドが「このデータが欲しい!」と宣言するだけで、バックエンドがその通りにデータを返してくれる、「必要なものを必要なだけ」取ってこれるみたいな考え方が面白いなと感じました。

これからフルスタックで開発するとなった時は、GraphQLを技術選定して、メリットやデメリットを検証してみたいなと感じました。

最後までお読みいただき、ありがとうございました!

この「学生ひよこ界隈が送るGo/Javaで実現する「はじめてのバックエンド」Advent Calendar 2025」では、GoJavaを使い、APIの作り方、データベースとの接続、テストやDockerといった気になったバックエンド技術の基本を振り返った学びを共有しています。

ぜひ他の記事もチェックして、筆者がこのひとりアドカレを完遂することができるか、確認してみてください(^^)

学生ひよこ界隈が送るGo/Javaで実現する「はじめてのバックエンド」Advent Calendar 2025

それでは、明日の「学生ひよこ界隈が送るGo/Javaで実現する「はじめてのバックエンド」Advent Calendar 2025」の記事もお楽しみに!

参考文献

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?