REST vs GraphQL vs gRPC vs Events

In one line

Four ways to shape an API, each best at something: REST for public resource APIs, GraphQL for flexible client-driven queries, gRPC for fast typed service-to-service calls, and events for asynchronous decoupling.

0/7 · 0%

Think of it like this

Ordering food. REST is a fixed menu with set dishes. GraphQL is a salad bar: you pick exactly what goes on your plate in one trip. gRPC is the kitchen's internal ticket system: terse, fast, and only the staff understand it. Events are the notice board: the kitchen posts 'order ready' and whoever cares reacts.

Key ideas

01
REST/JSON: universal, cacheable with HTTP, easy to debug with curl, the default for public and partner APIs. Weaknesses: over-fetching (too much data) or under-fetching (many round-trips) for complex screens.
02
GRAPHQL: one endpoint; the client sends a query naming exactly the fields and nested relations it needs; a schema types everything. Great for many different frontends. Costs: harder HTTP caching, N+1 query risks in resolvers (use DataLoader batching), and query-cost limits to stop expensive queries.
03
gRPC: Protocol Buffers schemas, binary encoding over HTTP/2, generated clients in many languages, streaming in both directions, deadlines built in. Ideal between internal services. Costs: not browser-native without a proxy (gRPC-Web), harder to inspect by hand, and needs L7 load balancing (Networking course, HTTP versions).
04
EVENTS (Kafka, SNS/SQS): the producer announces something happened (OrderPlaced); any number of consumers react later. Maximum decoupling and resilience, at the cost of eventual consistency and harder tracing. Most real systems combine them: REST/GraphQL at the edge, gRPC inside, events between domains.

Code & diagrams

the same data, three waystext

REST:     GET /users/42          → full user object
          GET /users/42/orders   → second round-trip

GraphQL:  query { user(id: 42) { name orders(last: 3) { id total } } }   → exactly that, one trip

gRPC:     service Users { rpc GetUser(GetUserRequest) returns (User); }   → typed, binary, generated client

Explain without notes

When would you choose gRPC over REST for service-to-service calls?

Practice

A company has a web app, iOS and Android apps with very different screens, and 40 internal microservices. Recommend API styles for each boundary.

Trade-offs

↔
Flexibility (GraphQL) vs cacheability and simplicity (REST); performance and typing (gRPC) vs accessibility (REST); decoupling (events) vs immediate consistency (sync calls).

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Networking · HTTP/1.1 vs 2 vs 3

Multiplexing, QUIC, and why gRPC needs L7 load balancing.

Completion checklist

I can pick an API style for a boundary and justify it
I know GraphQL's N+1 and caching pitfalls

Back to phase

Command Palette