REST vs gRPC vs GraphQL
REST, gRPC, and GraphQL are three widely used approaches to designing APIs between clients and services, and choosing among them is a recurring system design decision with real consequences for performance, developer experience, and evolvability. REST (Representational State Transfer) models an API as a set of resources manipulated via standard HTTP verbs (GET, POST, PUT, DELETE) and is prized for its simplicity, cacheability, and universal tooling support. gRPC is a binary, contract-first RPC framework built on HTTP/2 and Protocol Buffers, optimized for low-latency, high-throughput service-to-service communication. GraphQL is a query language for APIs that lets clients specify exactly which fields they need across potentially multiple resources in a single request, addressing over-fetching and under-fetching problems common in strict REST designs.
Cricket analogy: Choosing REST, gRPC, or GraphQL is like choosing between Test cricket, T20, and ODI formats — each format (verb-based simplicity, high-speed binary exchanges, flexible run-chases) suits a different match situation.
REST: Simplicity and Cacheability
REST's resource-oriented model maps naturally onto HTTP's semantics: a GET is safe and cacheable by intermediaries (browsers, CDNs, proxies) without any special logic, which is a major operational advantage at scale — a REST API can leverage standard HTTP caching infrastructure for free. Its downsides emerge with complex data needs: a mobile client that needs a user's profile plus their last 5 posts plus follower count might need three separate REST calls (or a bespoke aggregation endpoint), and a REST response often includes more fields than a given client actually needs (over-fetching) or requires follow-up calls to get related data (under-fetching).
Cricket analogy: A REST GET is like a scorecard app that any fan's browser can cache from the stadium screen without asking the scorer each time, but getting a player's stats plus last 5 innings plus team ranking might need three separate lookups.
gRPC: Performance for Service-to-Service Calls
gRPC serializes messages with Protocol Buffers — a compact binary format that is both smaller on the wire and faster to serialize/deserialize than JSON — and multiplexes many concurrent calls over a single HTTP/2 connection, avoiding the head-of-line blocking and per-request connection overhead that can affect HTTP/1.1-based REST. It also generates strongly-typed client and server code from a shared .proto schema, catching contract mismatches at compile time rather than at runtime. These properties make gRPC the dominant choice for internal service-to-service communication in microservice architectures, where every millisecond of latency and every byte of serialization overhead compounds across a request that may fan out to a dozen internal calls; it is less commonly exposed directly to browsers, since native browser support for HTTP/2 trailers and binary framing is limited without a proxy layer (e.g., gRPC-Web). GraphQL, by contrast, exposes a single endpoint backed by a strongly-typed schema, and clients send queries that specify exactly the fields and nested relationships they need, which a GraphQL server resolves — often by fanning out to multiple underlying REST or gRPC services or databases behind the scenes. This eliminates over-fetching and under-fetching from the client's perspective and is especially valuable for products with many different client types (web, iOS, Android, third-party) each needing different slices of the same underlying data. The trade-off is server-side complexity: naive resolver implementations can trigger the 'N+1 query problem' (a query that appears simple but triggers one database query per item in a list), and because GraphQL responses aren't cacheable via simple HTTP caching the way REST GETs are, caching requires additional infrastructure (e.g., persisted queries, response-level caching keyed by query+variables).
Cricket analogy: gRPC's compact protobuf messages over one multiplexed HTTP/2 connection are like a stadium's fiber-optic broadcast feed carrying every camera angle at once without re-dialing, while GraphQL is like a commentator fielding one flexible question that quietly triggers a dozen separate stat lookups if not careful (N+1).
REST: GET /users/42 -> full user object (may over-fetch)
GET /users/42/posts -> separate call for posts (under-fetch)
gRPC: client.GetUser(UserRequest{id: 42}) -> UserResponse (binary, typed, HTTP/2)
GraphQL:
query {
user(id: 42) {
name
posts(limit: 5) { title }
followerCount
}
}
-> single response with EXACTLY the requested fields, one round tripNetflix uses gRPC extensively for internal service-to-service communication (where performance and strong typing across hundreds of microservices matter most), while historically using REST/GraphQL-style APIs at the edge facing client devices — illustrating that these choices aren't mutually exclusive; large systems often use different API styles for different layers of the same architecture.
A common mistake is adopting GraphQL purely because it's popular, without accounting for its operational costs: query complexity limiting (to prevent a malicious or accidental deeply-nested query from overloading the server), resolver-level caching, and N+1 query mitigation (e.g., via DataLoader-style batching) all require deliberate engineering effort that a simple REST API often doesn't need.
- REST models APIs as HTTP-verb-manipulated resources, offering simplicity and free HTTP-level cacheability at the cost of over/under-fetching.
- gRPC uses binary Protocol Buffers over HTTP/2 for low-latency, strongly-typed communication, making it the default for internal service-to-service calls.
- GraphQL lets clients request exactly the fields they need in one round trip, solving over/under-fetching but shifting complexity to the server.
- gRPC's compile-time-checked contracts catch mismatches earlier than REST's typically looser, documentation-driven contracts.
- GraphQL requires deliberate engineering (query complexity limits, N+1 mitigation, custom caching) that plain REST APIs often avoid.
- These styles are not mutually exclusive; large systems commonly use gRPC internally and REST or GraphQL at the client-facing edge.
Practice what you learned
1. What is a key advantage of REST APIs related to HTTP infrastructure?
2. Why is gRPC commonly chosen for internal service-to-service communication in microservice architectures?
3. What problem does GraphQL primarily solve compared to a strict REST design?
4. What is the 'N+1 query problem' in the context of GraphQL?
5. Why might a large system use gRPC internally but expose REST or GraphQL at the client-facing edge?
Was this page helpful?
You May Also Like
Client-Server Architecture
The foundational model where clients request resources or services from centralized servers, including its variations, benefits, and inherent limitations at scale.
WebSockets and Long Polling
Compares techniques for pushing real-time updates from server to client, from wasteful short polling through long polling to full-duplex WebSocket connections.
Designing a News Feed System
Explores how systems like Facebook or Twitter assemble a personalized, ranked feed at scale, contrasting fan-out-on-write and fan-out-on-read delivery models.
Stateless vs Stateful Services
Explains the distinction between services that retain per-client state locally versus those that don't, and why statelessness is central to scalable system design.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics