What Is gRPC? RPC Meets HTTP/2
🔌 What Is gRPC? RPC Meets HTTP/2
api-design1-6 introduced the RPC model and JSON-RPC, then named gRPC as where that road leads next without going deep. This course picks up exactly there — starting with what gRPC actually is, why Google built it, and where it genuinely fits against REST and GraphQL.
The RPC Model, Recap
api-design1-6 drew the core distinction: REST thinks in terms of resources ("fetch this thing"), while RPC thinks in terms of function calls ("run this specific operation"). A JSON-RPC call like {"method": "getUser", "params": {"id": 104}} is calling a named function remotely, not fetching a URL representing a resource. gRPC is exactly that model, made concrete with a real schema, real code generation, and a purpose-built transport.
Why Google Built gRPC
gRPC grew out of an internal RPC system Google had used for years to connect its own services at enormous scale, open-sourced in 2015. It was designed first and foremost for service-to-service communication inside a company's own infrastructure — the traffic between a user service and an order service, for instance — not primarily for public-facing APIs a browser calls directly. That origin explains nearly every design choice covered in this chapter.
HTTP/2 as the Transport
Most REST APIs run over HTTP/1.1 with JSON bodies. gRPC runs over HTTP/2, and leans on two of its capabilities directly:
- Multiplexing — many requests and responses can flow concurrently over a single connection, without one slow request blocking others behind it (the "head-of-line blocking" problem HTTP/1.1 suffers from when reusing a connection).
- Binary framing — messages are encoded as compact Protocol Buffers binary (Chapter 2), not human-readable JSON — smaller payloads, faster to parse, at the cost of no longer being readable by just glancing at network traffic.
REST's Typical Stack vs. gRPC's Stack
REST
HTTP/1.1 (often), JSON bodies — human-readable, universally supported, easy to debug with curl or a browser.
gRPC
HTTP/2, Protocol Buffers binary — smaller and faster, but requires generated code and dedicated tooling to inspect.
gRPC vs. REST vs. GraphQL Positioning
api-design1-8 built a four-question decision framework across REST, SOAP, RPC-style, and webhooks — gRPC and GraphQL are the two remaining pieces of the full picture.
| REST | GraphQL | gRPC | |
|---|---|---|---|
| Model | Resources | Client-specified query shape | Function calls |
| Typical transport | HTTP/1.1, JSON | HTTP/1.1, JSON | HTTP/2, Protobuf binary |
| Contract | Often implicit/documented separately | A typed schema | A typed schema (.proto), code-generated |
| Best fit | Public APIs, broad client compatibility | Flexible client data needs | Internal service-to-service, high performance |
A First Glimpse: A .proto File
Chapter 2 covers the syntax properly — this is just a preview of what a gRPC schema-first contract looks like:
gRPC Tends to Fit
Internal microservice-to-microservice calls where both ends are code you control, high-throughput or low-latency requirements, and genuine streaming needs (Chapter 4).
REST/GraphQL Still Win
Public-facing APIs consumed by browsers or arbitrary third parties, situations needing easy debugging with just curl, and clients that can't run generated code.
💻 Coding Challenges
Challenge 1: RPC vs. REST, Revisited
Using api-design1-6's RPC-vs-REST distinction, explain in your own words why "call GetUser" and "GET /users/104" represent two different mental models, even though both might return the same data.
Goal: Practice restating the function-call vs. resource distinction in your own words before layering gRPC specifics on top.
Challenge 2: Explain Multiplexing's Benefit
Explain why HTTP/2 multiplexing matters for a gRPC client making many concurrent calls to the same service, compared to HTTP/1.1's limitations.
Goal: Practice connecting a specific HTTP/2 feature to a concrete performance benefit.
Challenge 3: Pick the Right Style
For each, recommend REST, GraphQL, or gRPC and justify: (a) a public API for third-party developers to integrate with, (b) high-frequency internal calls between an order service and an inventory service, (c) a mobile app that needs to fetch a customizable set of fields per screen.
Goal: Practice applying this chapter's positioning table to concrete, realistic scenarios.
A browser can't perform the low-level HTTP/2 framing and trailer handling gRPC needs directly — calling a gRPC service straight from browser JavaScript isn't possible without an intermediary (gRPC-Web, requiring a proxy that translates browser-compatible requests into real gRPC calls). This is a direct consequence of gRPC's service-to-service origins: it was never designed with "a browser calls this directly" as a primary use case, which is exactly why Chapter 8's public-vs-internal framing matters — reaching for gRPC for a public API a browser calls directly adds real friction REST or GraphQL simply don't have.
🎯 What's Next
The next chapter gets concrete: Protocol Buffers: Defining Your Schema — .proto file syntax, message types, field numbering rules, and why a schema-first contract beats REST's typically implicit ones.