gRPC, GraphQL and choosing a style

REST is the default, but it isn't the only style. Knowing the alternatives lets you pick the right one for each boundary in a design, and explain why in a sentence.

gRPC: fast, typed calls between services

gRPC lets one service call a function on another as if it were local. You define messages and methods in a .proto file, and code generators produce clients and servers in each language.

1 service Feed {
2   rpc GetFeed (FeedRequest) returns (FeedPage);
3   rpc StreamUpdates (FeedRequest) returns (stream FeedItem);
4 }

What makes it fast and safe:

• Protocol Buffers encode messages in compact binary, smaller and quicker to parse than JSON.
• HTTP/2 multiplexes many calls over one long-lived connection.
• Generated, typed clients catch mismatched fields at compile time, and the schema evolves safely when you only add fields.
• Streaming in either direction, or both, for long-running exchanges.

The trade-offs: browsers can't call gRPC directly without a proxy, binary payloads are hard to read while debugging, and every client needs the schema. That is why gRPC dominates inside a company, between microservices, while REST stays at the edge.

GraphQL: let the client choose the shape

GraphQL exposes one endpoint and a typed schema. The client sends a query describing exactly what it needs:

1 query {
2   user(id: 7) {
3     name
4     posts(first: 3) { title likeCount }
5   }
6 }

The server returns that shape and nothing more. This solves two real problems for product teams: over-fetching (a REST endpoint returns 40 fields when the screen shows 3) and under-fetching (a screen needs five endpoints, so five round trips).

It moves complexity to the server. A query can fan out into many database calls (the "N+1" problem, solved with batching loaders), arbitrary queries are hard to cache at a CDN, and you must protect the server from expensive queries with depth limits and cost analysis.

Picking a style

What interviewers listen for

You rarely need to debate API styles at length. One sentence per boundary is enough: "Clients call a REST API through the gateway; internally the feed service calls the graph service over gRPC because it's a hot path." What matters is that each choice has a reason tied to the requirement: who the callers are, how often they call, and what they need back.