GraphQL in Production · Advanced GraphQL

Choosing GraphQL Wisely

Where GraphQL shines, where it hurts, and hybrid architectures.

GraphQL shines for product APIs with many diverse clients (web, iOS, Android, partners) that need different data shapes, for aggregating many backend services, and for teams that value a typed, self-documenting contract. It's a poor fit for simple CRUD services, file transfer, public APIs that need simple HTTP caching and wide tooling, or high-throughput internal RPC (gRPC fits better). Many companies run hybrid architectures: GraphQL (or a BFF) at the edge for apps, REST for public/partner APIs, gRPC and events internally.

GraphQL vs REST vs gRPC

Criterion GraphQL REST gRPC
Client-driven data shapes Excellent Limited Fixed messages
HTTP caching / CDN Needs persisted GET Native No
Browser support Native Native Needs gRPC-Web/Connect
Streaming Subscriptions SSE/WebSockets Native bi-directional
Tooling for public APIs Good Ubiquitous Developer-focused
Typical home App edge / BFF Public & partner APIs Internal service-to-service

Common pitfalls

  • Adopting GraphQL for a single client with stable needs.
  • Exposing GraphQL publicly without cost controls.
  • Rewriting stable REST APIs for fashion.

Key points

  • Great for many clients and aggregation
  • REST for public/caching-heavy APIs
  • gRPC for internal RPC; hybrid is normal

Further reading: GraphQL FAQ

Practice questions

Give two scenarios where GraphQL is a strong fit.

Answer

A product with web and mobile apps needing different data per screen from many backend services; and an aggregation layer (BFF) over multiple microservices where client teams iterate quickly.

Why do many companies use GraphQL for apps but REST for public APIs?

Answer

Public consumers expect simple HTTP semantics, caching, tooling and stable URLs; first-party apps benefit most from flexible, typed queries and can use trusted documents.

Open in the app to mark lessons complete, take notes and track your progress.