What Is gRPC?
gRPC is an open-source remote procedure call (RPC) framework originally developed by Google and released in 2015 as the successor to their internal Stubby system. Instead of asking a service to send you a document like REST does, gRPC lets a client call a method on a remote server as if it were a local function, with the framework handling serialization, transport, and network communication over HTTP/2. It uses Protocol Buffers as its default interface definition language and wire format, which makes payloads compact and calls fast across any language that has a gRPC implementation, including Go, Java, Python, C++, and Node.js.
Cricket analogy: Calling a gRPC method is like a captain radioing instructions to a fielder from the pavilion during a DRS review — you issue a precise command ('move to deep square leg') and expect a direct, structured response, not a rambling report of the whole innings.
Core Building Blocks
Every gRPC service starts life as a .proto file, where you define messages (the data structures) and services (the collection of callable methods) using Protocol Buffer syntax. The protoc compiler, or a language-specific plugin, then generates client stub code and server skeleton code from that single definition, so a Python client and a Go server can talk to each other without either team hand-writing serialization logic. This code generation step is what gives gRPC strong typing and cross-language consistency: the .proto file is the single source of truth, and any change to it propagates to every generated client and server after regeneration.
Cricket analogy: The .proto file is like the official laws of cricket published by the MCC — every team, umpire, and broadcaster generates their own scorecards and match reports from that same rulebook, so a match in Mumbai and one in Melbourne stay consistent.
Communication Patterns
gRPC supports four RPC patterns: unary (one request, one response), server streaming (one request, a stream of responses), client streaming (a stream of requests, one response), and bidirectional streaming (both sides stream independently over the same connection). All four run over a single long-lived HTTP/2 connection, which multiplexes many concurrent calls without the head-of-line blocking that plagued HTTP/1.1, and lets a server push a continuous feed of results, such as live stock prices or sensor telemetry, without the client re-requesting each update.
Cricket analogy: Unary RPC is like a single review request to the third umpire that returns one verdict, while server streaming is like the ball-by-ball live commentary feed that keeps pushing updates to your radio for the entire session without you asking again.
syntax = "proto3";
package greeter.v1;
service Greeter {
// Unary RPC
rpc SayHello (HelloRequest) returns (HelloReply);
// Server streaming RPC
rpc SayHelloStream (HelloRequest) returns (stream HelloReply);
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}gRPC is widely used for internal microservice-to-microservice communication where low latency and strong typing matter more than human-readability, such as at Netflix, Square, and within Kubernetes' own control-plane components (etcd, kubelet).
Browsers cannot speak native gRPC directly because they lack low-level control over HTTP/2 trailers; you need grpc-web plus a proxy like Envoy, or a gateway that translates HTTP/1.1 JSON to gRPC, to call gRPC services from client-side JavaScript.
- gRPC is an RPC framework built on HTTP/2 that lets clients call remote methods as if they were local functions.
- It uses Protocol Buffers by default for compact, strongly-typed serialization instead of JSON text.
- A single .proto file is the source of truth from which client stubs and server skeletons are generated in many languages.
- gRPC supports four call patterns: unary, server streaming, client streaming, and bidirectional streaming.
- All calls multiplex over one persistent HTTP/2 connection, avoiding head-of-line blocking.
- Browsers need grpc-web and a proxy because they cannot use native gRPC directly.
- gRPC is most common for internal service-to-service communication, not public-facing browser APIs.
Practice what you learned
1. What transport protocol does gRPC run on by default?
2. What is the primary source of truth for a gRPC service's contract?
3. Which RPC pattern involves the client sending multiple requests and receiving a single response?
4. Why can't a browser call a gRPC service directly without additional tooling?
5. What organization originally created and open-sourced gRPC?
Was this page helpful?
You May Also Like
gRPC vs REST
A practical comparison of gRPC and REST covering serialization, performance, streaming, and when to choose each for an API.
Protocol Buffers Explained
How Protocol Buffers serialize structured data into a compact binary format, and why gRPC uses them as its default wire format.
Defining a .proto File
A practical guide to writing a .proto file: syntax declarations, messages, services, field rules, and naming conventions.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics