REST vs gRPC vs GraphQL

What it is

Three approaches to API design. REST uses HTTP verbs and resource URLs with JSON: simple, cacheable, universally supported. gRPC is a binary RPC framework over HTTP/2 using Protocol Buffers: strongly typed, fast, with streaming. GraphQL is a query language where the client specifies exactly which fields it needs from a typed schema, fetched through a single endpoint.

The problem it solves

Different API consumers have different needs. REST is the right default for public APIs and CRUD, since it's cacheable and every tool understands it. gRPC solves the overhead of JSON-over-HTTP/1.1 for chatty internal service-to-service calls. GraphQL solves over-fetching and under-fetching for clients (especially mobile) that would otherwise make many round-trips to assemble one screen.

How it works

REST: client hits resource URLs (GET /users/1) with HTTP verbs; responses are JSON; HTTP caching and status codes do real work. gRPC: define services and messages in a .proto file, codegen typed client/server stubs; calls are binary over HTTP/2 with multiplexing and bidirectional streaming. GraphQL: define a typed schema; clients send a query naming exactly the fields they want; a resolver layer fetches and assembles the response in a single round-trip.

Why use it

• REST: universal tooling, HTTP caching, dead simple, great for public APIs
• gRPC: compact binary payloads, HTTP/2 multiplexing, native streaming, contract-first typing, making it ideal internal RPC
• GraphQL: one request fetches exactly what the client needs across many resources, killing over/under-fetching for mobile

What it costs you

• gRPC: not browser-native (needs grpc-web + a proxy), binary payloads are hard to debug by eye, HTTP caching is gone
• GraphQL: server complexity (resolvers, N+1 query risk), caching is hard, a single malicious query can be very expensive
• REST: over-fetching/under-fetching and chatty round-trips for complex UIs; no schema unless you bolt on OpenAPI

Where it shows up in our architectures

• Netflix →

  REST/HTTP for client control-plane APIs through Zuul; gRPC-style binary RPC between internal microservices where latency matters

• Twitter Home Timeline →

  A GraphQL-style aggregation layer is a natural fit for assembling a timeline (tweets + authors + media + counts) in one round-trip for mobile

• Uber →

  Internal services use gRPC for low-latency, strongly-typed dispatch and geo calls; client apps talk REST/HTTP to the edge

Gotchas

• Default to REST for public and external APIs, since it's cacheable and every client speaks it. Reach for gRPC inside your fleet where you control both ends and want speed + typing.
• GraphQL's N+1 problem is brutal: a naive resolver fires one DB query per item in a list. You need DataLoader-style batching from day one.
• gRPC isn't browser-friendly. Browsers can't speak raw gRPC, so you need grpc-web and a translating proxy (Envoy), which erodes some of the appeal.
• GraphQL moves complexity to the server and makes caching and rate-limiting harder: a single deeply-nested query can cost more than a hundred REST calls. Enforce query depth/cost limits.