はじめに

この記事は、CA Tech Lounge Advent Calendar 2024 14日目の記事です！

今回は個人開発を中心に続けてきた自分が、GraphQLの便利さに感動したので、それについて話していきたいと思います。

そもそもGraphQLとは

公式ページには以下のように書かれています。

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

下記は翻訳です。

GraphQLはAPIのクエリ言語であり、既存のデータを使用して それらのクエリを実行するためのランタイムです。

難しいのでChatGPT先生に聞いてみました。

先生曰く、GraphQLは、APIから必要なデータだけを効率よく取得できる仕組みで、データの構造を明確にしながらAPIの進化や開発を 簡単にしてくれるツールらしいです。

少し抽象的なので、具体的な特徴を言うと、

• スキーマベースでAPIを定義できる
• 必要なデータを効率的に取れる
• 一つのエンドポイント

などが挙げられます。

使う前までの印象

そもそも自分は多少興味はもっていたものの、GraphQLをわざわざ学習してまで個人開発で利用する必要はないと思っていました。

実際に使う前までは、下記のような印象でした。

• フロント側からすきなデータをとってこれる
• 一つのエンドポイントからデータのやり取りが可能

軽く調べただけの状態ではこのくらいの印象しか残らず、便利そうだけどRESTで良くないか？とか、取得のデータが毎回違うと状態管理とか大変そうといった意見でした。

あと、個人開発なので、別にスキーマベースにAPI設計できてもなぁのように軽く考えていました。

きっかけ

では、どうして今GraphQL積極的に使っていきたい勢になったのかというと、実務で実際に使い始めたのがきっかけでした。

今半年ほどインターンしている会社にて、実際に実務でGraphQLを用いたアプリ開発を経験しました。

そこで感じたのが、「え、GraphQLええやん」です。

今ではとある個人開発のアプリは、Flutter・Go・GraphQLのようなスタックを用いて作成すると言う、実際に個人開発にGraphQLを取り入れるまでになりました。

では実際にどういう部分に魅力を感じたのかというと、大まかにわけてこの3つです。

• クライアントの状態管理などが楽になる
• スキーマファーストな実装が可能
• 複数クライアントでの実装が楽

実際に一つずつ説明します！

クライアントの状態管理などが楽になる

これは使う前に感じていた、取得するデータが毎回違うと大変そうという、無知が故の懸念点でした。 GraphQLではデータを正規化し、レスポンスを自動でキャッシュしてくれる機能が存在します。

GraphQLの真骨頂はデータの取得を簡単にすることではなく、クライアントのキャッシュにあるといっても過言ではないかもしれません。（異論は認める）

データをキャッシュ化してくれるので、新しくQueryを実行した場合、すでにキャッシュが存在していれば通信せずそのキャッシュを表示してくれます。

今まで、ReduxやJotai・TCA・Riverpodのような状態管理ライブラリを使って必死に状態管理をしてきましたが、ここまで自動でやってくれるのはかなり感動しました。

スキーマファーストな実装が可能

GraphQLでは、まず下のコードのようにスキーマという型の仕様書を定義します。

type Fish {
  ID: ID!
  ScientificName: String
  Data: FishData
}

type FishData {
  Name: String!
  Description: String
  ImageURL: String
  LanguageCode: LanguageCode!
}

enum LanguageCode {
  ja
  en
}

そして上記のようなスキーマを元に、クエリやミューテーションと呼ばれるデータの取得や更新をする役割のスキーマも定義します。 簡単にいうと、クエリというのはGETリクエストのようなデータを取得することで、ミューてションはPOST・PATCH・DELETEのようなデータを変更することを指します。

クエリやミューテーションもスキーマに定義します。 例えば、LanguageCodeをもとに、Fishというデータの一覧を返すクエリは下記のように記述できます。

extend type Query {
  fishList(languageCode: GetFishInput!): [Fish!]
}

input GetFishInput {
  languageCode: LanguageCode!
}

このようにAPIをスキーマベースに記述することが可能です。

RESTだとReactではaspidaのようなライブラリでリクエストやレスポンスに型をもたせることが可能ですが、GraphQLではこのように一つスキーマを定義するだけで、全てのFEやBEで共有することが可能です。

個人開発だからいいやなどと言っていましたが、普通に便利です。（というか最近Next.jsのプロジェクトでaspidaで一々型定義するのが面倒すぎました、、）

複数クライアントでの実装が楽

これは必要なデータを取得できるというメリットとほぼ同義なのですが、例えばモバイルではNameを表示するけどWebでは表示しないと行った場合、RESTだともう一つエンドポイントをはやさないと行けませんがGraphQLだ何も変更する必要はありません。

複数のクライアントがあるアプリほどメリットが増えるなと思いました。

GraphQLいいよね

個人開発RESTでよくね？ → GraphQLめちゃいいやんになった経験談でした。

自分のように少しでもGraphQL気になっている人がいれば、参考になると幸いです！

最後に

自分もまだまだ学習が足りないので、これからもGraphQLと向き合っていこうと思います〜。
何か指摘あれば是非お願いします🙏

（寝言）gRPCとかも使ってみたい

参考文献

• ジャンプTOON Flutter × GraphQL 宣言的なアプリ開発の工夫