gRPC
A fast, typed way for services to call each other using generated code, compact protobuf messages, and HTTP/2.
See it
What it is
gRPC makes a network call look like a typed function call. You describe services and messages in a Protocol Buffers .proto file, then protoc generates client and server code for languages such as Go, Java, Python, and Node.js. Messages are compact binary protobuf data, and HTTP/2 carries unary calls plus client, server, and bidirectional streams. It grew out of Stubby, the RPC system Google had been running internally for years before releasing gRPC in 2015.
Reach for it between services you control, especially when several languages need to share one strict contract or a stream must stay open. The generated stubs remove hand-written request code, deadlines travel with calls, and protobuf usually moves less data than JSON. A public or browser-facing API is often easier to operate as REST or GraphQL; browsers commonly need gRPC-Web and a compatible proxy.
The contract is durable, so protobuf field numbers are sacred. Rename a field if you must, but never reuse its old number for a different meaning; reserve removed numbers so an older message cannot be decoded as the wrong field. Also set deadlines and retry policies explicitly. A generated client can still wait forever or repeat a non-idempotent write if the transport policy is careless.
Ask AI for it
Build this service as a gRPC API with a proto3 .proto contract. Define request and response messages with stable field numbers, one unary RPC, and one server-streaming RPC; reserve every removed field number. Use protoc to generate the server and client stubs, map failures to standard gRPC status codes, propagate deadlines and cancellation, enable the standard gRPC health checking service, and include grpcurl commands that exercise both methods.