gRPC is a high-performance, open-source Remote Procedure Call (RPC) framework developed by Google that enables client and server applications to communicate efficiently across networks, as if calling local functions.
gRPC (Google Remote Procedure Call) is a modern communication framework that allows a program to execute a function on a remote server transparently. It was open-sourced by Google in 2015 and is now a Cloud Native Computing Foundation (CNCF) project. It is language-agnostic, meaning clients and servers can be written in different programming languages and still communicate seamlessly.
gRPC is significantly faster and more efficient than traditional REST APIs for inter-service communication, making it a popular choice for microservices architectures. It uses HTTP/2 as its transport layer, enabling multiplexing, bidirectional streaming, and header compression out of the box. These features reduce latency and bandwidth usage, which is critical at scale.
gRPC uses Protocol Buffers (protobuf) as its Interface Definition Language (IDL) and binary serialization format. You define your service methods and message types in a .proto file, and the gRPC toolchain auto-generates client and server code in your target language. The binary protobuf encoding is far more compact than JSON, resulting in smaller payloads and faster parsing.
gRPC supports four distinct call types: unary (single request, single response), server streaming (one request, stream of responses), client streaming (stream of requests, one response), and bidirectional streaming (simultaneous streams in both directions). This flexibility makes gRPC suitable for use cases ranging from simple CRUD operations to real-time chat and live data feeds. Choosing the right pattern for your use case is essential for optimal performance.
gRPC cannot be called directly from a web browser because browsers do not expose the low-level HTTP/2 framing that gRPC requires. To use gRPC in browser-based applications, you must use gRPC-Web along with a proxy like Envoy to translate between browser requests and gRPC. For public-facing APIs, REST or GraphQL is often still preferred, while gRPC shines for internal service-to-service communication.
Your .proto service definition is a contract shared between all clients and servers, so breaking changes can cascade across many services simultaneously. Always add new fields rather than removing or renumbering existing ones, since protobuf uses field numbers (not names) for serialization. Use API versioning strategies such as separate package namespaces (e.g., v1, v2) to manage breaking changes safely over time.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app