REST vs gRPC vs GraphQL

Analogy categoryAnalogies

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).

text

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 trip

Netflix 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?

DNS and CDNs

WebSockets and Long Polling

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Microservices Study Notes

Software Architecture · 30 topics

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Software Engineering Study Notes

Python · 40 topics

Software Engineering

Git & Version Control Study Notes

Bash · 40 topics

Topics covered

#Architecture#SystemDesignStudyNotes#SoftwareEngineering#RESTVsGRPCVsGraphQL#REST#GRPC#GraphQL#Simplicity#APIs#StudyNotes#SkillVeris

REST vs gRPC vs GraphQL