caduh

REST vs GraphQL vs gRPC — which one should you ship?

2 min read

A quick, practical guide to choosing between REST, GraphQL, and gRPC for new and existing services.

TL;DR

  • REST — simple, cache-friendly, great for public APIs and browser clients.
  • GraphQL — one endpoint, clients pick fields; ideal for complex UIs and multiple consumers.
  • gRPC — binary, fast, typed contracts; best for service-to-service (backend) calls.

What they look like

REST

GET /users/42
→ 200 OK
{ "id": 42, "name": "Ada", "email": "[email protected]" }

GraphQL

# POST /graphql
query {
  user(id: 42) { id name }
}

gRPC (proto)

syntax = "proto3";
service Users { rpc GetUser(GetUserReq) returns (User) {} }
message GetUserReq { int32 id = 1; }
message User { int32 id = 1; string name = 2; string email = 3; }

When to choose what

| Situation | REST | GraphQL | gRPC | |----------------------------------|:----:|:-------:|:----:| | Public API / 3rd-party devs | ✅ | ⚠️ | ❌ | | Simple CRUD resources | ✅ | ⚠️ | ❌ | | Rich UI needs flexible fields | ⚠️ | ✅ | ❌ | | Mobile: minimize round-trips | ⚠️ | ✅ | ❌ | | Microservices, low latency | ⚠️ | ⚠️ | ✅ | | Strong typing & contracts | ⚠️ | ⚠️ | ✅ | | HTTP caching / CDNs | ✅ | ⚠️* | ❌ |

* GraphQL can cache with persisted queries or custom keys, but it’s not “free” like REST GET.

Strengths & trade-offs

REST

Pros

  • Familiar, great tooling (curl, browsers, Postman).
  • Native HTTP semantics (status codes, ETag, Cache-Control).
  • Easy to expose publicly and document with OpenAPI.

Cons

  • Over/under-fetching (may need many endpoints).
  • Versioning can get messy.

Use when: simple resources, SEO/public endpoints, need CDN caching.

GraphQL

Pros

  • Client asks for exactly the fields it needs (less over-fetch).
  • One endpoint simplifies evolution; strong schema with SDL.
  • Great for complex UIs and multiple frontend teams.

Cons

  • Server complexity (N+1 pitfalls, caching is harder).
  • Needs governance (schema sprawl), extra gateway layer common.

Use when: complex product surfaces, many clients (web/mobile), fast iteration.

gRPC

Pros

  • Very fast (HTTP/2, binary Protobuf), streaming support.
  • First-class contracts; codegen across languages.
  • Great for internal service meshes.

Cons

  • Browsers need gRPC-Web or a proxy.
  • Not ideal for public/open APIs.

Use when: backend-to-backend, high throughput/low latency, polyglot microservices.

Practical decision recipe

  1. Start REST for any outward-facing API or simple app. Add OpenAPI + ETag.
  2. Add GraphQL when your UI has many views/clients and over-fetching hurts.
  3. Use gRPC behind the scenes for chatty, performance-sensitive service calls.
  4. Mix intentionally: REST at the edge, GraphQL for product surfaces, gRPC between services.

Security & ops quick notes

  • Auth: All three work with OAuth2/OIDC; gRPC typically uses mTLS internally.
  • Observability: Standardize tracing (W3C traceparent), log request IDs everywhere.
  • Versioning: REST via paths/headers; GraphQL via field deprecation; gRPC via backward-compatible proto changes.
← Back to all posts