Every backend eventually has the meeting. Someone benchmarks the JSON serialization in the hot path, someone else mentions that the new team is building their service in Go while everything else is TypeScript, and a third person says the word "gRPC" with either reverence or suspicion, depending on their last job. The conversation that follows tends to run on vibes.
It doesn't need to. gRPC is dramatically better than REST at a specific set of jobs and clearly worse at another set, and the line between them is drawable in advance. Here's the honest version.
What gRPC actually is
gRPC is a remote-procedure-call framework: instead of thinking in resources and verbs, you call what looks like a function on another machine. Three pieces make it what it is:
The contract comes first. You define services, methods and message shapes in a `.proto` file. That file is the API, language-neutral, versioned in git, and readable by every team.The code is generated. From that proto file, tooling generates typed clients and servers in Go, TypeScript, Python, Java, whatever you run. Nobody hand-writes an HTTP client or argues about a field name; the compiler enforces the contract on both ends.The wire is binary over HTTP/2. Messages are serialized as Protocol Buffers, several times smaller than equivalent JSON and cheaper to parse, and travel over HTTP/2 connections that multiplex many concurrent calls and carry streams in both directions.REST, by contrast, is a set of conventions over plain HTTP and (almost always) JSON: universally understood, readable by a human with curl, cacheable by every proxy on the internet, and enforced by nothing but discipline and documentation.
Where gRPC genuinely shines
Service-to-service traffic. Inside your backend, where no browser is involved, gRPC's trade-offs all point the right way: smaller payloads, one multiplexed connection instead of a pool, and typed stubs instead of hand-rolled clients. This is its home ground.Polyglot teams. The proto file becomes the single source of truth between the Go service, the Python ML service and the TypeScript API. Contract drift, the classic integration bug, gets caught at compile time instead of at 2am.Streaming. gRPC has four call shapes: plain request-response, server streaming (one request, a stream of responses, live prices, progress updates), client streaming (uploads, telemetry), and bidirectional streaming (chat, collaborative sessions). REST has request-response and a collection of workarounds.Low-latency hot paths. When a user request fans out into a dozen internal calls, shaving serialization cost and connection overhead off each hop adds up to latency a user can feel.Deadlines and cancellation, built in. A gRPC call carries its deadline with it, and cancelling a request propagates down the whole call chain, exactly what you want when a user abandons a page and forty downstream calls should stop working on their behalf.Where REST still wins, comfortably
Public APIs. Your customers' developers know REST, their tools know REST, and "here's a curl command" is the best onboarding documentation ever written. Handing third parties a proto file and a codegen toolchain is friction with no payoff.Browsers. Browsers can't speak native gRPC, the HTTP/2 framing it needs isn't exposed to JavaScript. gRPC-Web plus an Envoy proxy closes some of the gap, with limits, but it's machinery you don't need if a JSON endpoint would do.Debuggability. A REST call is readable in a terminal, a browser tab and every proxy log. A gRPC payload is binary; you can inspect it with grpcurl and good tooling, but "I can read the traffic with my eyes" is worth more than teams expect, especially during an incident.HTTP caching. GETs with cache headers, CDNs, conditional requests, REST inherits the web's entire caching infrastructure for free. gRPC largely opts out of it.Simple CRUD at human scale. If the API is a handful of endpoints serving a web app, REST's simplicity beats gRPC's efficiency every day of the week. | REST + JSON | gRPC |
|---|
| Contract | Documentation and discipline | Enforced .proto, codegen |
| Wire format | Text JSON | Binary Protocol Buffers |
| Transport | HTTP/1.1 (usually) | HTTP/2 |
| Streaming | Workarounds (SSE, WebSockets) | Native, four call shapes |
| Browser support | Universal | Via gRPC-Web + proxy |
| Human debuggability | Excellent | Needs tooling |
| Caching | Full HTTP ecosystem | Minimal |
| Best at | Public and browser-facing APIs | Internal service-to-service |
The benchmarks are real: Protocol Buffers serialize into payloads several times smaller than JSON, parsing binary is cheaper than parsing text, and HTTP/2 multiplexing removes connection overhead that HTTP/1.1 pays per request. On dense internal traffic, the difference is measurable and sometimes decisive.
But keep it in proportion. These are transport savings, milliseconds and bytes per call. If your endpoint spends 200ms in an unindexed query, gRPC gets you a 202ms endpoint instead of a 205ms one. If your architecture makes nine sequential hops to answer one question, the problem is the nine hops, not the serialization format. Teams that adopt gRPC *for performance* alone are often solving their third-biggest problem first. The contract and the streaming model are the durable wins; the speed is a welcome bonus.
The contract is the killer feature
The underrated half of gRPC is what the proto file does to team dynamics. It's API documentation that can't lie, because the code is generated from it. It's reviewable in a pull request. And its evolution rules are mechanical: add fields freely, never reuse a field number, never change a field's type, mark removed fields reserved. Those four rules, checkable by a linter, are the entire backward-compatibility story, which is more than most REST APIs can say about their changelog.
That's why the strongest gRPC adoption stories are about coordination, not speed: five teams, three languages, one set of proto files, and a class of integration bug that simply stopped happening.
Designing the seams between your services right now? This is exactly the territory of our
System Review and
consulting work, we'll help you draw the API boundaries once, correctly, instead of twice expensively.
A decision rule you can defend
The pragmatic answer for most systems is *both*, split along one clean line:
Inside the backend, service to service: gRPC. Enforced contracts, typed clients, streaming where it helps, efficiency as a bonus. If you're also splitting a monolith, the proto files double as the formal definition of your new service boundaries.At the edge, anything a browser or a third party touches: REST (or a gateway). Tools like grpc-gateway and Envoy's transcoding will even generate the REST layer from the same proto files, so the two worlds share one source of truth.Anything that shouldn't block: events. gRPC is synchronous; it doesn't replace your queue. Request-response goes over gRPC, "this happened" goes on the event stream.The bottom line
gRPC isn't a faster REST, it's a different tool: contract-first, binary, streaming-native, and built for the traffic between your services rather than the traffic from the outside world. Use it on the inside, where its strictness compounds across teams and its efficiency compounds across hops. Keep REST at the edge, where the web's tooling and readability still win. And if anyone in the meeting claims one of them is simply better, they've just told you which half of the problem they've been working on.
