RPC and gRPC contracts

RPC-style APIs expose **named procedures** with typed contracts — strong fit for internal service-to-service calls where HTTP resource modeling adds little value.

**gRPC** uses Protocol Buffers over HTTP/2:

					syntax = "proto3";
package orders.v1;

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc ListOrders(ListOrdersRequest) returns (stream Order);
  rpc CreateOrder(CreateOrderRequest) returns (Order);
}

message GetOrderRequest { string id = 1; }
message Order { string id = 1; string status = 2; }
				

Features:

• **Unary, server streaming, client streaming, bidi streaming**.
• **Deadlines/timeouts** propagated in metadata.
• **Status codes** mapped to `grpc-status` details.
• **Code generation** for many languages; breaking proto changes need discipline (field numbers, reserved).

Compared to REST: better performance and strict contracts; worse browser ergonomics (needs grpc-web or gateway). Use behind API gateway for public HTTP.

On interviews: when gRPC beats REST internally, streaming use cases, and protobuf compatibility rules (never reuse field numbers).

Common pitfalls: breaking proto without version bump, giant messages without pagination, missing deadlines, and exposing gRPC directly to browsers.

The trade-off is developer velocity in polyglot microservices versus human-readable HTTP debugging — invest in grpcurl, reflection, and observability.

Checklist:

• Proto packages versioned (v1, v2).
• Deadlines on every client call.
• Streaming for large reads/writes.
• Gateway or BFF for external clients.