gRPC

RPC is a different mental model

RPC (remote procedure call) exposes the server as named procedures with typed arguments and returns, rather than modeling everything as HTTP resources with verbs. gRPC is Google’s mature RPC framework. It is not REST — it prioritizes strong contracts, binary efficiency, and first-class streaming.

In interviews, gRPC appears for internal microservices, not as the default public API for browser clients.

What “RPC style” means

Client code calls something like:

rpc CreateOrder(CreateOrderRequest) returns (Order);

instead of:

POST /orders
Content-Type: application/json

The contract — method names, message fields, types — lives in an IDL (interface definition language). Tooling generates client and server stubs in Java, Go, TypeScript, Python, etc. Schema drift surfaces at build time, not only in production when JSON fields disagree.

gRPC building blocks

Protocol Buffers (protobuf)

Define messages and services in a .proto file:

message CreateOrderRequest {
  string customer_id = 1;
  int64 amount_cents = 2;
}

service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (Order);
}

Field numbers are stable on the wire; adding new optional fields is forward-compatible if clients ignore unknown fields.

HTTP/2 transport

gRPC runs over HTTP/2: one connection, multiplexed streams, header compression (HPACK). Many small concurrent calls share a connection efficiently — useful inside data centers where latency between services dominates.

Four call types

1. Unary — one request, one response (closest to classic HTTP request/response).
2. Server streaming — one request, many responses (log tail, event stream, large result sets chunked).
3. Client streaming — many requests, one response (upload chunks, batch ingest).
4. Bidirectional streaming — both sides send streams (chat, collaborative editing, real-time feeds).

REST can approximate streaming via SSE or WebSockets separately; gRPC treats streams as native RPC shapes.

Metadata, status, deadlines

• Metadata — analogous to HTTP headers: auth tokens, trace ids, tenancy keys.
• Status codes — gRPC uses its own codes (NOT_FOUND, INVALID_ARGUMENT, DEADLINE_EXCEEDED). HTTP mapping exists under the hood; service authors think in gRPC status.
• Deadlines / timeouts — clients propagate “fail if not done by T”; servers can cancel work when deadline passes. Critical for avoiding hung call chains in microservices.

gRPC-Web

Browsers do not speak native HTTP/2 gRPC everywhere without help. gRPC-Web translates to something browsers can use, often behind Envoy or similar proxies. Public browser → backend APIs still often expose REST or GraphQL at the edge; gRPC stays service-to-service.

When gRPC shines

• Internal microservices in the same organization — generated stubs, strict contracts, polyglot teams.
• High throughput, low overhead — binary protobuf vs JSON parse/serialize on hot paths.
• Streaming — metrics, logs, replication, real-time pipelines as first-class RPC types.
• Strong evolution story — .proto as single source of truth with compatibility rules.

Trade-offs

JSON-RPC is a lighter RPC-over-JSON style (different ecosystem from gRPC) — useful to name when the interviewer asks about alternatives without protobuf.

BFF pattern

Mobile and web clients talk REST/GraphQL to a backend-for-frontend that aggregates calls over gRPC to internal services. Keeps public contracts simple; keeps internal efficiency.

Interview framing

“When gRPC over REST?” — Internal services needing typed contracts, performance, streaming, generated clients — not when you need broad HTTP caching of public reads or trivial browser consumption without grpc-web/BFF.

“How do errors work?” — gRPC status codes on the RPC layer; map to HTTP at gateways for external clients if needed.

“Unary vs streaming?” — Unary for request/response CRUD-like calls; server streaming for push/log scenarios; bidirectional for live sessions.

Next: GraphQL — client-shaped reads on a schema-driven graph.