GraphQL vs REST vs gRPC

Three API styles, three trade-off profiles — pick the right one for your clients and latency budget.

AdvancedTheory12 min read

Read these first

REST API Design for Systems

StreamHub's mobile app uses GraphQL to fetch stream metadata, chat preview, and follower count in one round trip. Internal microservices talk gRPC. Third-party partners consume REST. One platform, three API styles — each chosen for its audience.

Side-by-side comparison

Aspect	REST	GraphQL
Data fetching	Fixed endpoints; over/under-fetching common	Client specifies exact fields needed
Transport	HTTP/1.1 + JSON	HTTP POST + JSON (typically)
Schema	OpenAPI (optional, external)	Built-in introspection schema
Caching	HTTP cache headers work natively	Harder — POST-only; needs persisted queries
Best client	Public third-party integrations	Mobile/web apps with varied data needs

Data fetching
RESTFixed endpoints; over/under-fetching common
GraphQLClient specifies exact fields needed
Transport
RESTHTTP/1.1 + JSON
GraphQLHTTP POST + JSON (typically)
Schema
RESTOpenAPI (optional, external)
GraphQLBuilt-in introspection schema
Caching
RESTHTTP cache headers work natively
GraphQLHarder — POST-only; needs persisted queries
Best client
RESTPublic third-party integrations
GraphQLMobile/web apps with varied data needs

Aspect	gRPC	When to pick
Transport	HTTP/2 + Protocol Buffers (binary)	Internal service-to-service calls
Performance	Smallest payload, fastest serialization	High-QPS microservice mesh
Streaming	Bidirectional streaming built-in	Real-time telemetry, log pipelines
Browser support	Needs grpc-web proxy	Not for direct browser clients
StreamHub use	Stream service ↔ chat service ↔ notification service	Never exposed to browsers directly

Transport
gRPCHTTP/2 + Protocol Buffers (binary)
When to pickInternal service-to-service calls
Performance
gRPCSmallest payload, fastest serialization
When to pickHigh-QPS microservice mesh
Streaming
gRPCBidirectional streaming built-in
When to pickReal-time telemetry, log pipelines
Browser support
gRPCNeeds grpc-web proxy
When to pickNot for direct browser clients
StreamHub use
gRPCStream service ↔ chat service ↔ notification service
When to pickNever exposed to browsers directly

REST — StreamHub public API

API protocol placement

NETWORKREST / GraphQLAPI Gateway · public

COMPUTEgRPC internalEKS · mTLS

NETWORKWebSocketALB sticky · chat

REST/GraphQL at edge via API Gateway; gRPC service-to-service inside VPC.

Simple, cacheable, well-understood. Partners integrate with curl and any HTTP library.

Java

GET /v1/streams/live_9912 HTTP/1.1
Accept: application/json
Authorization: Bearer eyJ...

Strengths: HTTP caching, CDN-friendly GETs, massive tooling ecosystem. Weakness: mobile home screen needs 4–5 REST calls for one view.

GraphQL — StreamHub mobile BFF

Java

query StreamDashboard($streamId: ID!) {
  stream(id: $streamId) {
    title
    viewerCount
    streamer { displayName avatarUrl }
    recentClips(limit: 3) { id thumbnailUrl }
  }
}

GraphQL trade-offs

Pros: One request, no over-fetching, strong typing via schema, great for mobile.
Cons: N+1 query risk (solve with DataLoader batching), complex caching, query depth attacks.
Mitigation: Max query depth limit, complexity scoring, persisted queries for production.

gRPC — internal mesh

Java

service StreamService {
  rpc GetStream(GetStreamRequest) returns (StreamResponse);
  rpc StreamViewerCount(ViewerCountRequest) returns (stream ViewerCountUpdate);
}

message GetStreamRequest {
  string stream_id = 1;
}

gRPC advantages internally

10× smaller payloads than JSON — matters at 50K internal QPS.
Strong contracts via protobuf; breaking changes caught at compile time.
Streaming RPCs for live viewer count push between services.
mTLS + service mesh (Envoy/Istio) handles auth and retries transparently.

Decision framework

Scenario	Pick	Reason
Public partner API	REST + OpenAPI	Universal tooling, HTTP caching
Mobile app home screen	GraphQL BFF	One round trip, flexible fields
Service-to-service calls	gRPC	Speed, streaming, strong typing
Real-time chat delivery	WebSocket (not REST/GraphQL/gRPC)	Persistent bidirectional connection
High-throughput event ingestion	Kafka (not an API style)	Async log, not request/response

Public partner API
PickREST + OpenAPI
ReasonUniversal tooling, HTTP caching
Mobile app home screen
PickGraphQL BFF
ReasonOne round trip, flexible fields
Service-to-service calls
PickgRPC
ReasonSpeed, streaming, strong typing
Real-time chat delivery
PickWebSocket (not REST/GraphQL/gRPC)
ReasonPersistent bidirectional connection
High-throughput event ingestion
PickKafka (not an API style)
ReasonAsync log, not request/response

Quick recall

Everything you need if you only revisit this box.

REST: simple, cacheable, best for public APIs and third-party integrations.
GraphQL: client-driven queries, one round trip, needs depth limits and DataLoader.
gRPC: binary, fast, streaming — internal service mesh only (grpc-web for browsers).
StreamHub: REST public, GraphQL mobile BFF, gRPC internal, WebSocket for real-time.
Pick by client type and latency budget, not hype.
All three need auth, rate limiting, and observability regardless of style.

Test yourself

Answer these before moving on — recall is what makes it stick.