gRPC

Google’s open RPC framework: describe a service in a .proto file, generate typed clients and servers, and call them over HTTP/2 with streaming, deadlines and standard status codes.

What it is: Remote procedure calls
Type: Open source
Made by: The gRPC Authors (CNCF), started at Google
License: Apache 2.0 since June 2017 (BSD 3-Clause before); the gRPC-Rust preview is MIT
Facts checked: 6 October 2026

What it is

You describe a service and its messages in a .proto file, and the Protocol Buffers compiler, with a gRPC plugin, generates a client stub and a server base class for your language. The client calls a stub method like a local function. The library encodes the request as Protobuf and sends it as an HTTP/2 request to /package.Service/Method with content-type: application/grpc; the server’s generated code decodes it and calls your handler. Each message carries a 5-byte prefix (a compression flag and its length), so one call can carry many messages, and the outcome comes back as a status code and message in HTTP/2 trailers. That allows four call shapes: unary (one request, one response), server streaming, client streaming and bidirectional streaming, all multiplexed over one long-lived connection. A client sets a deadline, sent as the grpc-timeout header; the server can see it and stop working, and the call fails with DEADLINE_EXCEEDED. Interceptors wrap every call for logging, auth or metrics, and standard services cover health checks and reflection.

The client also picks the server. A name resolver (DNS by default) returns addresses, and a load-balancing policy chooses one per call: pick_first by default, or round_robin and others named in the service config, which also holds per-method timeouts and retry policies. With xDS, that configuration can come from a control plane such as Google’s Cloud Service Mesh, for a service mesh with no sidecar proxy. gRPC is free and open source and has been a CNCF incubating project since 2017. There is no single implementation: the C++ core in grpc/grpc also powers Python, Ruby, PHP and Objective-C, while Go, Java, Kotlin, Node, .NET, Swift, Dart and Rust (a preview since May 2026) live in separate repositories with their own releases and feature sets.

Why teams pick it

One .proto contract generates typed clients and servers in a dozen languages, so a Go service and a Python caller agree on every field
Streaming in both directions over one multiplexed HTTP/2 connection, with flow control
Deadlines, cancellation, retry policies and a fixed set of status codes are part of the framework, not reinvented by each team
Wide infrastructure support: Envoy, NGINX, AWS ALB and Cloud Run carry it, and Kubernetes can probe pods with the gRPC health protocol
Client-side load balancing and xDS let large fleets skip the proxy hop entirely

Watch out for

Browsers can’t make gRPC calls, because browser APIs expose neither HTTP/2 frames nor trailers. gRPC-Web needs a translating proxy (Envoy by default) and supports only unary and server-streaming calls, the latter only in text mode
Long-lived HTTP/2 connections defeat connection-level load balancing: behind a Kubernetes Service or another L4 balancer, every call from a client can land on one pod. You need an L7 proxy, client-side balancing or a mesh, and every hop must pass HTTP/2 and trailers (on ALB, an HTTPS listener and a gRPC target group)
Harder to debug: payloads are binary Protobuf, so curl and browser dev tools don’t help; you need the .proto files or server reflection plus a tool such as grpcurl or Postman
No deadline by default: a client that doesn’t set one can wait for a response forever
Features differ by language: each implementation has its own repository and release cycle, xDS support covers only some of them, and a client silently ignores xDS settings it doesn’t support

Alternatives

What all remote procedure calls have in common →

Apache ThriftOpen sourceFacebook’s 2007 RPC framework: define types and services in one IDL file, generate clients and servers for over 20 languages, and pick the wire protocol and transport separately.

Cap’n ProtoOpen sourceA binary format laid out like an in-memory struct, so reading needs no parse step, plus an RPC system built on object references and promise pipelining.

Protocol BuffersOpen sourceGoogle’s schema-first binary encoding: messages defined in `.proto` files, fields identified by number, code generated for each language.

How it fits with other technologies

What gRPC uses

What uses gRPC

A Python client with round-robin balancing, retries and a deadline · python

# pip install grpcio grpcio-tools   (protos_and_services compiles the .proto at import)
#
# orders.proto
#   syntax = "proto3";
#   package shop.v1;
#   service Orders {
#     rpc GetOrder (GetOrderRequest) returns (Order);
#     rpc WatchOrders (WatchRequest) returns (stream Order);  // server streaming
#   }
#   message GetOrderRequest { string id = 1; }
#   message WatchRequest { string customer_id = 1; }
#   message Order { string id = 1; string status = 2; int64 total_cents = 3; }
import json

import grpc

pb, pb_grpc = grpc.protos_and_services("orders.proto")

service_config = {
    "loadBalancingConfig": [{"round_robin": {}}],  # default pick_first uses one backend
    "methodConfig": [{
        "name": [{"service": "shop.v1.Orders"}],
        "retryPolicy": {
            "maxAttempts": 3,
            "initialBackoff": "0.1s",
            "maxBackoff": "1s",
            "backoffMultiplier": 2,
            "retryableStatusCodes": ["UNAVAILABLE"],
        },
    }],
}

# dns:/// returns every address behind the name, so round_robin can spread calls
channel = grpc.insecure_channel(
    "dns:///orders.internal:50051",
    options=[("grpc.service_config", json.dumps(service_config))],
)
stub = pb_grpc.OrdersStub(channel)

try:
    order = stub.GetOrder(pb.GetOrderRequest(id="o-1042"), timeout=0.5)  # deadline
    print(order.status, order.total_cents)
except grpc.RpcError as err:
    if err.code() != grpc.StatusCode.DEADLINE_EXCEEDED:
        raise
    print("orders service too slow; showing the cached status")

for update in stub.WatchOrders(pb.WatchRequest(customer_id="c-77"), timeout=60):
    print("update:", update.id, update.status)

gRPC, REST with JSON, and Connect#

Connect is a newer Protobuf RPC protocol and library family that also speaks gRPC, so it is the usual alternative when browsers or plain HTTP tools matter.

	gRPC	REST with JSON	Connect
Contract	A `.proto` file, required	Optional, often an OpenAPI document	A `.proto` file
Encoding	Binary Protobuf by default; other payloads possible	JSON text	Binary Protobuf or JSON
HTTP version	HTTP/2 or later	Any	HTTP/1.1, HTTP/2 or HTTP/3; bidirectional streaming needs HTTP/2
Streaming	Unary, server, client and bidirectional	Not defined by the style	Unary, server, client and bidirectional
Errors	Status code and message in HTTP/2 trailers	HTTP status codes	No trailers, so any HTTP infrastructure can carry it
From a browser	Only through gRPC-Web and a proxy	Directly	Directly; also serves gRPC-Web without a proxy
With `curl`	No; use reflection and `grpcurl`	Yes	Yes, for unary calls with JSON

Connect servers accept gRPC, gRPC-Web and Connect requests, and Connect clients can call any gRPC server. Connect RPC has been a CNCF sandbox project since April 13, 2024.

Main implementations#

Each language has its own library and release schedule; check the one you use for features such as xDS.

grpc/grpc

C++ core

The C++ library, also wrapped by the Python (grpcio), Ruby, PHP and Objective-C packages. The older C# package built on it, Grpc.Core, is in maintenance mode.

grpc-java and grpc-go

standalone

Separate implementations in Java (with grpc-kotlin on top) and Go, each with its own releases. Both have supported xDS since 1.30 in June 2020.

grpc-dotnet and grpc-node

standalone

The recommended C# implementation since May 2021, and @grpc/grpc-js for Node.js.

grpc-web

browsers

A JavaScript client that talks to gRPC services through a proxy, Envoy by default. Unary and server-streaming calls only.

grpc-rust

preview

First preview in May 2026, client only, built on Tokio and Google’s Protobuf-Rust. Not recommended for production yet; MIT-licensed.

See it in a real stack

No architecture uses gRPC yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2015–2026

For over a decade Google connected its internal microservices with one general-purpose RPC system, Stubby, which by 2016 handled tens of billions of requests per second. Stubby wasn’t based on any standard and was too tied to Google’s infrastructure to release. Once SPDY, HTTP/2 and QUIC had put many of its features into public standards, Google decided to rebuild it on top of them and make it fit mobile, IoT and cloud use too.

Google open-sourced the result as gRPC on February 26, 2015, under a BSD licence, built on the just-finalised HTTP/2 standard, with Square as an early partner replacing its own RPC system. Its published principles favoured services and messages over distributed objects, streaming, flow control, cancellation and timeouts, a small set of standard status codes, and a layered protocol that doesn’t care about the payload format. Version 1.0 followed in August 2016.

gRPC joined the CNCF in February 2017 and switched to Apache 2.0 that June. It became plumbing for cloud-native software: etcd and containerd used it early, Kubernetes’ kubelet talks to container runtimes over it, and Envoy’s xDS configuration APIs are gRPC streams, which gRPC clients themselves have consumed since 2020 for meshes without sidecars.

Why it’s built this way

Standard HTTP/2 instead of a custom transport: The wire protocol had to survive “traversal over common internet infrastructure”. HTTP/2 already offered multiplexed streams, flow control and header compression, the features Stubby had built for itself.
Protobuf by default, but payload-agnostic: The principles said services need different encodings (Protobuf, JSON, XML, Thrift) and pluggable compression, so the protocol frames opaque messages and the .proto file is only the default.
Deadlines and cancellation in the protocol: Expensive, long-lived operations let servers reclaim work when the client gives up, and cancellation can cascade down a chain of calls instead of each service guessing its own timeout.
A small, fixed set of status codes: Clients handle errors in a few ways, so a constrained namespace (such as UNAVAILABLE or DEADLINE_EXCEEDED) makes retry and error decisions clear; richer detail goes in metadata.

Timeline

2015
Open-sourced February 26 under a BSD licence, with Square
2016
1.0 in August for C++, Java, Go, Node, Ruby, Python and C#
2017
Joins the CNCF in February; moves to Apache 2.0 in June
2018
gRPC-Web generally available in October
2020
xDS support in 1.30 enables proxyless service meshes
2026
First gRPC-Rust preview in May

Sources33 · facts checked 6 October 2026

Improve this page on GitHub