gRPC vs REST: reach or speed?

REST models resources over plain HTTP with human-readable JSON. Its superpower is universality — nothing to install, cacheable by any proxy, debuggable with a browser or curl, understood everywhere. gRPC takes a contract-first approach: you define messages and services in a protobuf file and generate typed clients/servers in every language, sending compact binary over HTTP/2 with multiplexed streams and native streaming. Its superpower is efficiency and type safety between machines.

The speed gap isn't marketing — it comes from two concrete mechanical differences. First, payload encoding: JSON repeats every field name as a string in every message ({"user_id": 42, "user_name": "..."}), while protobuf encodes each field as a small numeric tag defined once in the .proto schema — the wire format never re-sends "user_id" as text, just a tag byte and the value. For small messages the difference is modest; for high-volume internal traffic (millions of calls between services) it adds up to meaningfully less bandwidth and, just as importantly, less CPU spent parsing text into structured data on both ends.

Second, transport: REST over HTTP/1.1 opens one request per connection at a time (or relies on connection pooling to fake concurrency), while gRPC's HTTP/2 foundation multiplexes many concurrent calls over a single TCP connection — no head-of-line blocking between unrelated requests, no repeated TLS handshake overhead per call. Combined with native bidirectional streaming (a single call that sends and receives a continuous sequence of messages, not just one request and one response), this is what makes gRPC a genuinely different tool for chatty internal traffic — many small, frequent calls between services — rather than just "REST but smaller."

Say a ride-hailing app needs to stream a driver's GPS position to the rider's app every second while a trip is active — and separately, expose a public API partners can query for trip receipts. These are genuinely different problems, and the comparison table above explains why they get different tools.

The driver-location stream is exactly gRPC's native case: a server-streaming RPC where the driver's phone opens one call and the server pushes a continuous sequence of position updates over it, multiplexed alongside dozens of other gRPC calls that phone might be making (trip status, chat messages) on the same HTTP/2 connection. Modeling this in REST would mean either polling ("GET /driver/location every second," wasteful and laggy) or reaching for Server-Sent Events or WebSockets — workable, but bolted onto HTTP rather than native to the protocol the way gRPC's streaming is.

The trip-receipt API for partners is exactly REST's native case: a partner's backend (maybe written in a language with no gRPC tooling investment, maybe just curling it from a script during integration testing) wants GET /v1/trips/{id}/receipt returning JSON it can read directly, cache at a CDN edge if it's immutable, and debug by pasting the URL into a browser. Forcing this through gRPC would mean every partner needs a gRPC-Web proxy and generated client code just to fetch a receipt — friction with no payoff, since receipt-fetching isn't high-frequency or latency-sensitive the way the location stream is.