はじめに
最近、「GraphQL不要論」がよく流れてくる。
でもその一方で、「クライアント主導の柔軟なAPIが作れる」「型安全で保守しやすい」なんて声も多い。
自分は、NestJS + Prisma + PostgreSQL で社内向けシステムを作ってるけど、**この構成にGraphQLはアリなのか？**という点をガチで考えた。
この記事は「GraphQLをまだ導入してないけど、めちゃくちゃ悩んでる人の思考整理メモ」みたいなもの。
同じように考えてる人に届けば嬉しい。
✅ 現状構成：NestJS + Prisma + REST
まず今のバックエンド構成。
- フレームワーク：NestJS
- ORM：Prisma（PostgreSQL接続）
- API：REST（
@Controller+ DTO + Service） - フロント：Next.js、社内用Reactアプリ
RESTで必要十分だし、開発スピードも出る。
DBのスキーマとPrismaが直結してるおかげで型安全も担保されてる。
🤔 なぜGraphQLを検討したのか？
理由は1つ：
「フロント側で指標を柔軟に作りたくなった」
RESTだと、例えばこんなケースが辛くなる。
-
/campaigns/:id/metricsのレスポンスを変えるたびにバックエンド修正が必要 - 指標の数が増えてくるとエンドポイント設計が破綻し始める
- 「impressionsとclicksだけ欲しい」ってときでも全部返すか、API分けるしかない
GraphQLならこうなる：
query {
campaign(id: "abc123") {
impressions
clicks
}
}
そしてフロント側で CTR = clicks / impressions を計算する。
「バックはデータを提供するだけ、どう使うかはクライアントに任せる」 という思想にピッタリ。
🔍 GraphQL不要論は気にするべき？
いろいろ読んだけど、だいたい以下の内容：
| 不要論の主張 | 実感としてどうか？ |
|---|---|
| RESTで十分なケースが多い | 確かに社内用途ならRESTで完結することが多い |
| GraphQLは学習コストが高い | Nestならそれなりに自然に書けるが、スキーマ設計はやっぱり別モノ |
| Apolloが重い | 一理ある。クライアントが多いなら利点大きいけど、単一UIなら過剰感もある |
| N+1地獄になる | Prismaなら include や select である程度制御可能だけど意識は必要 |
なので、「何に使うか」が重要。
いま自分のプロジェクトでいきなり全部GraphQLにするのは違うけど、外部向けAPIや将来的な展開を考えると、今から設計目線でGraphQLを意識しておくのはアリだと思ってる。
✅ 現時点の自分の結論
- 社内向けの管理系UIやバッチ処理はRESTで十分
- 指標APIやフロント主導の柔軟なデータ取得にはGraphQLを検討したい
- Prisma + NestJS なら、RESTからGraphQLへの切り替えも段階的に進められる
いまはGraphQL導入前だけど、その検討過程で見えた選定軸や判断基準は、同じように悩んでる人の参考になるはず。
💡 余談：GraphQL導入フェーズで考えてること
- BFF的に外部向けだけGraphQLにする構成
- 認可処理の粒度（フィールド単位でやる？モジュール単位で切る？）
- metricsテーブル作るべきか、GraphQLで生データ返してクライアントで計算させるか
🙌 最後に
GraphQLは「今使うべきか？」じゃなくて、「どこで使うべきか？」が重要な気がする。
この記事はまだ「実装前の話」だけど、むしろそういう時期に書いておくと後で自分で見返したときに意味あると思う。
GraphQL、使わない理由もあるけど、使いたくなる理由もちゃんとある。