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.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Level 12: Search Autocomplete exercises a rich, well-versioned API surface.