How gRPC Works
IntermediategRPC is a high-performance framework for service-to-service calls. You define a service and its messages in a .proto file using Protocol Buffers; a compiler generates strongly-typed client and server code in many languages. Calls travel over HTTP/2 as compact binary Protobuf, which is far smaller and faster than JSON. gRPC also supports streaming — client, server, and bidirectional — making it a favourite for internal microservice communication where performance and strict contracts matter.
Think of a pre-agreed order form versus free text
REST with JSON is like writing your order in plain English — flexible, but the reader must parse it and both sides can disagree on wording. gRPC is like a pre-printed order form (the .proto contract) with numbered fields: both parties have the exact same form, tick boxes efficiently (binary Protobuf), and machines fill it out from a shared template (code generation). It is terser, faster to process, and impossible to fill in the wrong field.
Step by Step
Key Concepts
Protocol Buffers (Protobuf)
A language-neutral binary serialisation format and interface definition language. The .proto file defines messages and services; Protobuf encodes data far more compactly than JSON.
Code Generation
The protoc compiler turns the .proto contract into typed client stubs and server interfaces in many languages, so remote calls feel like local method calls and both sides stay in sync.
HTTP/2 Transport
gRPC runs on HTTP/2, gaining multiplexed streams over one connection, header compression, and native support for long-lived streaming calls — key to its performance.
Streaming Modes
Beyond simple unary calls, gRPC supports server-streaming, client-streaming, and bidirectional streaming, enabling real-time data flows within a single call.
Key Facts
- Binary Protobuf over HTTP/2 makes gRPC significantly faster and smaller on the wire than JSON over HTTP, especially for chatty internal traffic.
- The .proto contract gives strong typing and versioned, backward-compatible schemas — you cannot accidentally send a mistyped field.
- Browsers cannot speak raw gRPC directly, so public/browser APIs use REST or gRPC-Web; gRPC shines for internal service-to-service calls.
Real-World Applications
Internal microservice communication
Services call each other via gRPC for low latency and strict contracts, so a schema change breaks the build (caught early) rather than failing silently at runtime like a loose JSON API.
Streaming data between services
A service streams a large result set or continuous updates to another using server or bidirectional streaming, handling the flow within one efficient HTTP/2 call.
Frequently Asked Questions
What is gRPC and how does it work?
gRPC is a high-performance remote procedure call framework. You define your service and message types in a .proto file using Protocol Buffers, and a compiler generates typed client and server code. Calls are serialised to compact binary Protobuf and sent over HTTP/2, so invoking a remote method feels like calling a local function while being fast and strongly typed.
What is the difference between gRPC and REST?
REST typically uses JSON over HTTP/1.1 with resource URLs, is human-readable, and works everywhere including browsers. gRPC uses binary Protocol Buffers over HTTP/2 with a strict .proto contract and code generation, making it faster, smaller, strongly typed, and capable of streaming. REST is better for public, browser-facing APIs; gRPC excels at high-performance internal service-to-service communication.
What are Protocol Buffers?
Protocol Buffers (Protobuf) are a language-neutral, binary serialisation format and interface definition language from Google. You describe your data and service in a .proto file, and Protobuf encodes messages into a compact binary form that is much smaller and faster to parse than JSON. It also serves as the versioned contract from which gRPC generates typed code.
What are the four types of gRPC calls?
Unary (a single request and single response, like a normal function call), server streaming (one request, a stream of responses), client streaming (a stream of requests, one response), and bidirectional streaming (both sides stream messages simultaneously). HTTP/2 makes these streaming modes possible within a single call, which is useful for real-time and large-data scenarios.