GraphQLが流行りづらい点
そもそもGraphQLとは
概要
クライアントが必要なデータを正確に指定して取得できる柔軟性を提供してくれるもの。
RESTAPIの代替として登場し、クライアントとサーバー間のデータ通信を効率化することを目的としています。
以下のような特徴を持っています。
- スキーマ駆動型: APIはスキーマによって型安全かつ構造化されています。
- 単一エンドポイント: すべてのリクエストは単一のエンドポイント（例: /graphql）で処理されます。
- クライアント主導型: クライアントが取得するデータの形式や範囲を細かく指定可能です。
- リアルタイム対応: サブスクリプション機能により、データのリアルタイム更新が可能です。
GraphQLのメリット
下記が挙げられます。（他にもあると思いますが、、）
- 柔軟なデータ取得
オーバーフェッチやアンダーフェッチの防止 - 単一エンドポイント
複数のエンドポイントを使うRESTとは異なり、GraphQLはすべてのリクエストを単一のエンドポイントで処理できる - スキーマ駆動型
スキーマがAPIの仕様を明確に定義し、クライアントとサーバー間の契約を保証します。
開発者は型安全性が高まる。 - クライアントとサーバー間の整合性
クライアントが必要なデータ構造をサーバーに指示するため、フロントエンドのニーズに応じたAPIを簡単に作れます。 - リアルタイム対応
サブスクリプションを活用すれば、リアルタイムでデータを受信するWebSocket通信を簡単に実装できます。
本題：これだけのメリットがあってなぜ普及しないのか
学習コストが高い
一番の理由はここかなと思います。
GraphQLの導入には、スキーマ設計やリゾルバの実装など、割と準備が必要です。
何より、RESTAPI根強い普及もあると思いますが。。
パフォーマンスの課題
-
N+1問題：クライアントが必要なデータを自由に指定できる一方で、リゾルバ設計が適切でないとバックエンドでN+1クエリ問題を引き起こします。これを回避するためにはDataLoaderのようなツールを使う必要がありますが、追加の開発負担となります。
-
オーバーフェッチとアンダーフェッチの可能性：必要なデータだけを取得できるメリットがある反面、複雑なクエリを実行することでバックエンドに過剰な負荷をかけるリスクがあります。
キャッシングの課題
RESTAPIはエンドポイントごとにキャッシュが容易ですが、GraphQLは単一のエンドポイントで動作するため、HTTPキャッシュが難しいケースがあります。
特定ユースケースに特化しすぎている
GraphQLが必要でない場面が多い。
データ取得の柔軟性が必要な場合や、複数の異なるクライアントが同じAPIを利用する場合にはGraphQLは有効ですが、こうしたユースケースは限定的なのかなと思っています。
割と、RESTや後述するgRPCの方が適切であることも。
トレンドの移り変わり
新しい技術への移行。
GraphQLは「RESTの代替」として話題になりましたが、現在は他の技術（例：gRPC、tRPCなど）が注目を集めています。
結論
タイトルとして流行りづらいと述べましたが、流行る云々に
プロジェクトの導入・運用コスト等を検討した結果、見送るケースが多く、下降傾向にあるのかもしれないと思いました。
それでも、適切に利用すれば強力なツールであり、用途やプロジェクト規模に応じて選択する価値があります！
Discussion