gRPC

gRPC gRPC Google's RPC implementation: typed, fast, multi-language service-to-service calls over HTTP/2 using Protobuf for serialization. is Google's RPC implementation: typed, fast, multi-language service-to-service calls over HTTP/2 HTTP/2 A newer version of HTTP that carries many messages over one long-lived connection at once. gRPC builds on it for streaming and speed. with Protobuf Protobuf Protocol Buffers: a schema language and compact binary format underneath gRPC. You define messages once in a .proto file and generate code for many languages. binary serialization Serialization Turning in-memory data into bytes that can be sent over a network or saved, and back again on the other side (deserialization). . It works in three steps:

1. Write a .proto file: define your messages and service methods once. This is the contract .proto file The schema file where you define Protobuf messages and gRPC services. The protoc compiler turns it into typed code. : language-agnostic and source-controlled.
2. Run protoc: the compiler protoc The Protobuf compiler. It reads a .proto file and generates typed client and server stubs in the languages you need. reads the .proto and generates typed client and server stubs Stub Generated client or server code that makes a remote call look like an ordinary function: it serializes the arguments, sends them, and deserializes the reply. in any language: Go, Java, Python, Node, Rust.
3. Call it like a function: your code calls the generated stub. It serializes arguments to binary, sends them over HTTP/2, and deserializes the response, transparently.

// What you write (any language, this is Node)
bookService.checkoutBook({ id: 1 }, (err, book) => {
  // ...use the returned book
});

//   → looks like a local function call
//   → under the hood: Protobuf binary → HTTP/2 → server → Protobuf binary back

Error handling is different

gRPC abstracts HTTP away completely. You never return an HTTP 404; instead, gRPC has its own set of 16 standard status codes (NOT_FOUND, FAILED_PRECONDITION, UNAVAILABLE) that the generated stubs surface as errors in your language.

// Server-side: signal failure with a gRPC status code, not an HTTP one
checkoutBook: (call, callback) => {
  const book = books.find((b) => b.id === call.request.id);
  if (!book?.available) {
    return callback({ code: grpc.status.FAILED_PRECONDITION, message: "Not available" });
  }
  book.available = false;
  callback(null, book);
},

Built-in streaming

Streaming is a first-class primitive in the contract, not a bolt-on. You declare the mode right in the .proto by marking the request and/or response with stream, and protoc generates a stub whose shape matches: a method that returns a single value, or one you read from (and write to) like an ordinary stream. Because it all rides over a single long-lived HTTP/2 connection, many messages multiplex over one socket with no per-message handshake.

// Example .proto file, explored further in the next section
service BookService {
  // unary: one request, one response
  rpc CheckoutBook(BookRequest) returns (Book);

  // server streaming: mark the response with 'stream'
  rpc ListBooks(Filter) returns (stream Book);

  // client streaming: mark the request
  rpc UploadCatalog(stream Book) returns (UploadSummary);

  // bidirectional: mark both
  rpc Chat(stream Message) returns (stream Message);
}

REST has no equivalent in the contract. You reach for a separate mechanism like SSE, WebSockets, or chunked responses and wire it up by hand. In gRPC the four modes are just method signatures:

When to use gRPC

Use it when…

• Internal microservices: same data center, high volume, performance matters. Google, Kubernetes, and Uber all use gRPC internally.
• Multi-language teams: one .proto generates typed stubs for every team's language.
• You need streaming: IoT telemetry, video feeds, live analytics.
• You want strict contracts: a breaking change is a compile error, not a runtime surprise.

Skip it when…

• Public APIs (usually): external developers expect REST + JSON. (Tools like gRPC-Gateway can translate a gRPC service into a REST API automatically.)
• Browser clients: browsers can't speak raw gRPC. JavaScript APIs like fetch don't expose HTTP trailers during streaming, which gRPC requires. You need a proxy layer like gRPC-Web or ConnectRPC.
• Simple CRUD services: the protoc toolchain overhead isn't worth it for a small service.
• You need readable traffic: binary Protobuf is opaque to curl and browser DevTools.