gRPC

What is gRPC?

gRPC is a high-performance Remote Procedure Call framework from Google. You define your service’s methods and message types in a Protocol Buffers (.proto) schema, and gRPC generates strongly-typed client and server code in many languages. Calls go over HTTP/2 with messages serialized as compact binary Protobuf rather than JSON. The result is fast, strongly-typed, contract-first communication — which is why gRPC became a default for service-to-service calls inside microservices backends.

Why it’s fast — and why the browser is a problem

gRPC’s performance comes from two choices. Protocol Buffers serialize to compact binary that’s far smaller and faster to parse than JSON. HTTP/2 brings multiplexing (many calls over one connection), bidirectional streaming, and header compression. Together they make gRPC excellent for high-throughput, low-latency internal APIs, and its streaming support (client, server, and bidirectional streams) handles real-time data flows that request/response REST handles awkwardly. The catch — and it’s a real one — is the browser: browsers can’t speak raw gRPC because they don’t expose the low-level HTTP/2 control gRPC needs, so browser clients require gRPC-Web and a proxy translation layer. This is the single biggest reason gRPC dominates backend-to-backend traffic but rarely serves browsers directly.

gRPC vs REST vs GraphQL

The honest positioning against the alternatives. REST: simpler, human-readable JSON, universally supported, ideal for public APIs and browser clients — the safe default. GraphQL: solves client-driven data fetching and over-fetching, great for flexible frontends aggregating many resources. gRPC: wins on raw performance and strong typing for internal service meshes where both ends are yours and you control the stack. Many architectures use all three — gRPC between backend services, REST or GraphQL at the public/browser edge. Choosing gRPC for a public API that browsers must consume directly is the classic mismatch; choosing REST for a chatty high-volume internal path leaves performance on the table.

What people get wrong

• Exposing gRPC directly to browsers — you need gRPC-Web and a proxy; raw gRPC won’t work in a browser.
• Using it for public APIs: the binary contract-first model is worse than REST for third-party developers who want readable, discoverable endpoints.
• Ignoring tooling cost — Protobuf schemas and code generation add build-pipeline complexity that only pays off at scale.

Primary source: gRPC documentation