GraphQL arrived as the answer to REST over-fetching and rode the hype wave from 2016 through 2020. By 2026 it beats REST where clients need to shape their own responses and loses where simple CRUD suffices. Three real cases show the decision.

What GraphQL delivers

Clients shape responses and eliminate over-fetching on constrained networks, the typical mobile app situation. One query aggregates multiple resources in a single round trip instead of three chained REST calls. The typed schema doubles as documentation and contract at once, validated in CI with tools like graphql-schema-linter.

What it costs

  • N+1 queries without DataLoader-style batching; each field resolves in its own database round trip
  • Query depth attacks demand depth analyzers and configured complexity limits
  • Caching loses free HTTP semantics; persisted queries hand back part of the control
  • Every client couples to the schema, and the team preserves that contract forever

Case 1: a mobile-first product

Screen-driven schemas cut payload by 60% against a chatty REST layer making five calls per view. Battery drain and shaky 4G turned the savings into measurable retention.

Case 2: an internal admin panel

Five users hitting simple CRUD. The GraphQL ceremony delivered nothing REST missed, and the maintenance burden stayed anyway. REST plus OpenAPI would have covered it in a weekend.

Case 3: a public API platform

GitHub and Shopify justify GraphQL through client diversity: thousands of third-party integrations consuming varied data shapes. Teams exposing one frontend to one backend collect little of that payoff. Consumer diversity is the trigger, not fashion.

Federation at scale

Apollo Federation and The Guild tools compose graphs across teams, with a central router and contracts per subgraph. Powerful at organizational scale, heavy machinery under ten engineers: router operating cost outweighs the benefit on small teams.

Alternatives that took over

  • tRPC gives end-to-end types across TypeScript monorepos with no extra runtime
  • REST with OpenAPI codegen covers most CRUD surfaces
  • JSON:API handles sparse fieldsets when clients pick their fields

The decision rule

Many independent clients consuming varied data shapes justify GraphQL. One or two first-party frontends almost never do. Decide by consumer count, not by roadmap enthusiasm.