What Is gRPC, and How Is It Different From REST?

gRPC is an open source remote procedure call (RPC) framework, built by Google and now developed under the Cloud Native Computing Foundation (CNCF), that lets a program on one machine call a method on a program running somewhere else as if it were a local function call. It uses Protocol Buffers instead of JSON to define services and encode data, runs over HTTP/2, and is the framework many backend teams reach for when microservices need to talk to each other quickly and reliably. The short version of the "gRPC vs REST" question: REST is built around resources, text formats, and the HTTP tooling the web has used for decades; gRPC is built around strongly typed function calls, a compact binary format, and native support for streaming data in both directions.

What is gRPC?

According to the official gRPC documentation, "a client application can directly call a method on a server application on a different machine as if it were a local object," which is the core idea behind any RPC framework: it hides the network behind an ordinary-looking function call. A server implements the methods a service defines, and a client gets a local "stub" that exposes those same methods and forwards the calls over the network.

The name itself is explained in the project's own FAQ: gRPC stands for "gRPC Remote Procedure Calls," a recursive acronym in the spirit of other open source project names. The framework's homepage describes it simply as "a high performance, open source universal RPC framework."

gRPC traces back to an internal Google system called Stubby, which the company used to connect services for roughly a decade and a half before deciding, in March 2015, to build a new, open version of it — the project that became gRPC, according to Wikipedia's history of the project. gRPC itself was released in August 2016 and is licensed under Apache 2.0, meaning it's free to use, modify, and ship in commercial software.

How gRPC works: services, Protocol Buffers, and generated code

Where a typical REST API is described informally — a README, an OpenAPI file, a wiki page — a gRPC service is defined formally in a .proto file using Protocol Buffers, which grpc.io calls "Google's mature open source mechanism for serializing structured data." By default, gRPC uses protocol buffers as both the interface definition language (IDL) for describing a service's methods and the wire format for encoding the messages those methods send and receive, though the framework can be used with other data formats such as JSON.

That .proto file is run through the protoc compiler with a gRPC plugin, which generates client and server code — including the message classes — in whatever language you're targeting. The official documentation recommends using proto3, the newer version of the Protocol Buffers language, specifically because it's supported in more languages and avoids compatibility issues that can arise between proto2 and proto3 endpoints. In practice, this means a team can define a service once and generate working, type-checked client libraries for a Go backend, a Python data pipeline, and a Java mobile SDK from the same source file, rather than hand-writing an HTTP client against a REST contract in each language.

Officially supported languages include C++, C#/.NET, Dart, Go, Java, Kotlin, Node, Objective-C, PHP, Python, Ruby, Rust, and Swift, per the grpc/grpc GitHub repository and the project's language pages. If your team is choosing a backend language for a new gRPC service, it's worth reading how Rust and Go compare for the kind of networked, concurrent workloads gRPC is typically used for — both are first-class, officially supported gRPC languages.

Underneath the generated stubs, every gRPC call travels over a channel, which the documentation defines as providing "a connection to a gRPC server on a specified host and port." A channel can be reused across many calls, and gRPC's own request/response lifecycle adds features REST doesn't give you for free: per-call deadlines that cause a call to fail with a DEADLINE_EXCEEDED error if the server doesn't respond in time, the ability for either side to cancel an in-flight call immediately, and metadata — key-value pairs, such as authentication tokens, attached to a call separately from its main payload.

What is gRPC streaming? The four RPC types

One of the most-asked follow-up questions about gRPC is what makes its streaming different from a normal API call. The answer is that gRPC defines four distinct call patterns, not just one, and the pattern is part of the service definition itself:

• Unary RPC — the client sends a single request and gets a single response back, the same shape as a typical REST call or a plain function call.
• Server streaming RPC — the client sends one request, and the server sends back a sequence of messages over time. gRPC guarantees message ordering within an individual call, so results arrive in the order the server sent them.
• Client streaming RPC — the client sends a stream of messages to the server, which replies with a single response once it's ready.
• Bidirectional streaming RPC — both sides open independent read/write streams over one connection, and per the documentation, "the two streams operate independently, so clients and servers can read and write in whatever order they like."

This is only practical because gRPC runs on HTTP/2, which multiplexes many streams over a single TCP connection. The project's FAQ puts it this way: gRPC "largely follows HTTP semantics over HTTP/2 but we explicitly allow for full-duplex streaming." REST, by contrast, is built around a single request producing a single response, so long-lived, bidirectional data flows — live telemetry, chat-style updates, progressive results from a long-running job — usually require workarounds like polling, long-lived HTTP connections, or a separate WebSocket layer bolted on next to the REST API.

gRPC vs REST: a side-by-side comparison

Both are ways of letting one piece of software call another over a network, but they start from different assumptions: REST models a system as resources you fetch, update, and delete over plain HTTP; gRPC models it as a set of typed functions you call, serialized in a compact binary format.

The practical upshot: REST's text-based, HTTP/1.1-friendly design is why it has remained the default for public and browser-facing APIs — anyone with a browser or curl can poke at a REST endpoint and read the response. gRPC's binary encoding and generated clients trade some of that casual accessibility for smaller payloads, stricter contracts, and built-in streaming, which is why it tends to show up inside a system rather than at its public edge.

Can you call gRPC from a browser?

Not directly, and this is one of the more common points of confusion for developers new to the framework. gRPC relies on HTTP/2 features — including trailers, which carry status information after the response body — that browsers don't expose to JavaScript in the way gRPC needs. The project addresses this with a separate layer, gRPC-Web, which runs in the browser and talks to a proxy that translates calls into regular gRPC on the backend. In other words, a gRPC service that needs to serve a web frontend directly usually still exposes a REST (or gRPC-Web) layer at the edge, while using plain gRPC for the internal calls behind it.

What is gRPC used for?

gRPC shows up most often in a few recurring situations:

• Microservice-to-microservice communication — the scenario it was designed for: many small backend services, often written in different languages, calling each other frequently and needing low latency and strict typing.
• Polyglot systems — because protoc generates idiomatic client and server code for each supported language from one shared .proto file, teams can mix languages (say, a Go API layer talking to a Python data service) without hand-maintaining separate client libraries, as discussed in the official introduction to gRPC and protocol buffers.
• Streaming workloads — anything that benefits from a server pushing a continuous sequence of updates, or a client uploading a stream of data, without the overhead of repeated request/response cycles or a separate WebSocket implementation.
• Connecting mobile or IoT clients to backend services, a use case Google and the broader gRPC community have pointed to given the framework's compact binary payloads, which matter more on constrained networks and devices.

It's less commonly the right choice for a public-facing API consumed directly by third-party developers or browsers, precisely because of the browser limitation above and because JSON-over-REST remains the format most external API consumers expect out of the box.

Who maintains gRPC: Google and the CNCF

gRPC originated at Google but isn't governed by Google alone today. Per the Cloud Native Computing Foundation's own project page, gRPC was accepted into the CNCF on February 16, 2017, at the Incubating maturity level — the same neutral foundation that also hosts Kubernetes and Envoy — and the gRPC homepage itself still describes the project as "a CNCF incubation project." Day-to-day development happens in the open on GitHub, where the core grpc/grpc repository hosts the shared C++ core and language bindings that other official implementations build on.

If your team is already standardizing on CNCF-adjacent, cloud-native infrastructure — containerized services, service meshes, and the kind of in-memory data layers covered in our explainer on what Redis is and when to use it — gRPC tends to fit naturally into that stack, since many service meshes and cloud-native tools are built with gRPC-based communication in mind from the start.

Getting started with gRPC

Because gRPC's workflow is build-the-contract-first, getting started looks different from standing up a REST endpoint. The usual steps, per the official documentation, are: write a .proto file describing your service's methods and messages; run it through protoc with the appropriate gRPC plugin for your language to generate client and server code; implement the actual method logic on the server side; and call the generated stub methods from the client as if they were local functions. Teams coming from a REST or even a version-control background that's new to this kind of generated, contract-first workflow may find it a useful parallel to how a tool like Git formalizes collaboration around a shared history — our explainer on what Git is and how it differs from GitHub covers that formal-contract-versus-informal-convention tradeoff from a different angle.

What's next for gRPC

gRPC's trajectory inside the CNCF has been toward more governance and wider adoption rather than away from it: the project has continued to broaden official language support and tooling (including gRPC-Web for browser clients) since joining the foundation in 2017. For teams evaluating it today, the practical path is usually incremental rather than all-or-nothing — introducing gRPC for new internal services or performance-sensitive paths while keeping REST at the public edge, then expanding its footprint as more of the system is rebuilt around typed, generated contracts. Anyone building or maintaining services that mix the two will likely keep watching how gRPC-Web matures and how CNCF governance around the project evolves, since both affect how far gRPC can realistically reach beyond backend-to-backend calls.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage