GraphQL & gRPC: When to Reach Beyond REST
You'll learn to
- -Explain over-fetching/under-fetching and how GraphQL addresses it
The Problem: Over-fetching and Under-fetching
A REST endpoint returns a fixed shape. If it returns 30 fields and a mobile client only needs 3, that's over-fetching (wasted bandwidth). If rendering one screen needs data from three different endpoints, that's under-fetching: wasted round trips. Both get worse as an API surface grows.
GraphQL
The client describes exactly which fields it needs, across however many related resources, in a single query, solving over-fetching and under-fetching at once. The cost moves to the server: naive resolvers can trigger an "N+1" query problem, issuing one database query per related item instead of one batched query.
gRPC
Google's RPC framework, using Protocol Buffers for compact binary serialization instead of JSON, often 5-7x faster to serialize and transmit. Excellent for internal, service-to-service traffic where every millisecond compounds across a call chain, less suited to public browser-facing APIs without an extra translation layer.
ScaleDojo's API Design lab track goes much deeper on REST, GraphQL, and API architecture generally; this chapter is the on-ramp, not the whole story.
Should you rewrite your public REST API in GraphQL because your mobile app is over-fetching data?
"Yes, GraphQL solves over-fetching, so switch entirely."
"I'd scope it more narrowly first. GraphQL solves over/under-fetching well, but it moves complexity server-side (resolver N+1 problems, harder HTTP-level caching, a steeper operational learning curve), a real cost, not a free upgrade. Introducing a GraphQL layer specifically for the mobile client, while leaving simple, cacheable REST endpoints for everything else, often captures the benefit without forcing every consumer through the same trade-off."
Why is cursor-based pagination more stable than offset-based pagination?
Level 12: Search Autocomplete exercises a rich, well-versioned API surface.