gRPC

gRPC is a remote procedure call framework originally developed by Google for high performance service to service communication. Its core idea is simple: instead of one service talking to another through loosely defined JSON payloads, teams define a contract for requests and responses and generate client and server code from that contract. The contract is usually written in Protocol Buffers, or Protobuf.

A Protobuf schema defines message types and service methods. From that schema, tools generate strongly typed code in many languages. That gives teams a shared interface with less manual boilerplate and fewer shape mismatches at runtime. The wire format is compact and binary rather than textual, which usually means smaller payloads and faster serialisation than JSON.

Transport matters too. gRPC commonly runs over HTTP/2, which allows multiplexed streams on one connection, header compression, and long lived connections that are efficient inside datacentres. It also supports several interaction patterns: unary calls for simple request response traffic, server streaming, client streaming, and bidirectional streaming. That makes it useful for internal APIs, event style flows, and systems that need long lived data exchange rather than isolated HTTP requests.

These design choices make gRPC attractive for microservices, but they come with tradeoffs. Binary payloads are less pleasant to inspect by hand than JSON. Browser support is limited because the web platform does not expose raw HTTP/2 in the same way as backend runtimes, so direct browser use usually requires gRPC Web or a translation proxy. That makes gRPC stronger for internal systems than for public APIs aimed at many third party consumers.

Compatibility also needs care. Schema evolution is safer than ad hoc JSON if teams follow the Protobuf rules, such as not reusing field numbers and being deliberate about optionality. If they do not, the type safety only moves the breakage into generated code. Operational tooling matters as well. Load balancers, observability agents, and auth layers need to understand long lived streams, metadata, deadlines, and retries.

Deadlines are one of the most important parts of the model. A gRPC call should usually carry an explicit timeout so one slow dependency does not cause request chains to hang indefinitely. Retries also need method awareness. Retrying an idempotent read is very different from retrying a state changing write.

In practice, gRPC is best thought of as an internal API contract system with efficient transport. It gives teams structure, strong typing, and good performance when services are controlled by the same organisation. It is not automatically faster in every scenario, and it does not remove the usual distributed systems concerns around timeouts, versioning, or failures. What it does do well is make those concerns more explicit and more machine checked than a hand maintained collection of informal HTTP endpoints.