Best gRPC Tooling

Every team that migrates a service to gRPC hits the same wall, usually about a week after the first production deploy. Traffic works. Latency is better. Then the service scales out under load, three new pods come up, and the new pods receive essentially nothing while the original ones stay pinned at high CPU. Somebody restarts a client to prove a point, load moves, and the mystery deepens.

That is not a gRPC bug. It is the direct consequence of gRPC running many concurrent requests over one long-lived HTTP/2 connection, and of your load balancer balancing connections rather than requests. It catches everyone once. It is the single most useful thing to understand before you adopt gRPC, and it is almost never in the tooling comparisons.

The rest of the gRPC experience has a similar shape: the protocol is excellent, the default developer experience is rough, and the tools in this category exist to fill specific gaps. You cannot open a gRPC endpoint in a browser tab. You cannot curl it. You cannot call it from browser JavaScript without a translating proxy. And the moment more than one team generates code from the same .proto files, you need a registry and breaking-change detection or you will ship an incompatible field number and find out from a customer.

This guide covers the two standards underneath, the four operational problems that actually matter, and then the tools. Most readers here are mid-migration, moving internal REST services to gRPC, so the emphasis is on what breaks during that move rather than on greenfield purity.

Key takeaways

• gRPC multiplexes requests over persistent HTTP/2 connections, so any connection-level (L4) load balancer will pin a client to one backend. Scaling out does nothing until you move balancing to L7 or to the client.
• Protobuf compatibility is about field numbers, not field names. Renaming a field is safe on the wire and breaks generated code; reusing a retired number is safe in generated code and corrupts data on the wire.
• Browsers cannot speak gRPC. You either run a translating proxy for gRPC-Web, accepting that bidirectional streaming is not available, or adopt a protocol designed to work over plain HTTP.
• Server reflection is what makes gRPC debuggable with generic clients, and it is also an unauthenticated schema disclosure endpoint. Decide deliberately whether it is on in production.

gRPC: the protocol underneath, not a product

gRPC is an open specification and a set of implementations, not something you buy. There is no vendor, no licence and no bill. It defines how a remote procedure call is framed over HTTP/2: the request is a POST to a path derived from the service and method name, metadata travels as HTTP/2 headers, the message body is a length-prefixed sequence of frames, and the call’s outcome arrives in trailers as a numeric status code rather than an HTTP status.

That last detail explains several surprises at once. The HTTP status of a successful gRPC call is 200 even when the call failed, because the real status is grpc-status in the trailers. Anything in your stack that reads HTTP status codes, which includes most load balancer health logic, most WAF rules and most naive monitoring, will report success on every failed call.

What it gives you

• Four call shapes from one definition: unary, server streaming, client streaming and bidirectional streaming, with streaming as a first-class concept rather than a bolted-on upgrade
• Binary framing and header compression over HTTP/2, which is why gRPC wins on payload size and connection efficiency against JSON over HTTP/1.1
• Deadlines that propagate: a client-set deadline travels in metadata and every well-behaved hop downstream inherits the remaining budget, which is a genuinely better cancellation story than REST timeouts
• A defined status code space with retry and hedging semantics expressed in a service config, so retry policy is configuration rather than per-client code
• Generated clients and servers in many languages from one interface definition, which is the reason cross-language teams adopt it

What it does not do

• It does not work in a browser. Browser JavaScript cannot control HTTP/2 frames, so a direct gRPC call from a web page is not possible under any circumstances
• It does not survive L4 load balancing sensibly, because its connection model assumes something above the transport is distributing individual requests
• It does not give you human-readable traffic. You cannot read a request off the wire or paste one into a bug report without tooling
• It does not define schema governance. Where .proto files live, who may change them, and what counts as a breaking change are all outside the spec
• It does not map cleanly onto existing HTTP infrastructure: path-based routing works, but caching, URL-shaped rules and anything reading response status do not

Protocol Buffers: the schema language, also not a product

Protobuf is the other standard in play, and it is worth separating because the failure modes are different. It is a specification for an interface definition language and a binary wire format, with a compiler and runtime libraries. Again: no vendor, no bill.

The single most important property is that the wire format carries field numbers, not field names. A serialized message is a sequence of key-value pairs where the key encodes the field number and the wire type. Names exist only in the .proto file and in generated code.

What it gives you

• Compact binary encoding where unset fields cost nothing, which is why protobuf messages are dramatically smaller than the equivalent JSON
• Forward and backward compatibility as a design property: a reader that does not recognise a field number skips it using the wire type, so old servers tolerate new clients and the reverse
• A canonical JSON mapping, so the same schema can serve a binary internal path and a JSON debugging or browser path without a second definition
• Generated types in every major language from one file, which makes the schema the actual contract rather than documentation of one

What it does not do

• It does not stop you breaking compatibility. Nothing in the compiler prevents reusing a retired field number, changing a field’s type, or moving a field in or out of a oneof, and each of those silently corrupts data for readers built against the other version
• It does not distinguish “absent” from “default” unless you ask. In proto3, a scalar field set to zero and a scalar field never set serialize identically, which means a partial update that sets a counter to zero is indistinguishable from one that leaves it alone, unless the field is declared with explicit presence
• It does not handle unknown enum values gracefully in every language. Some runtimes preserve the unknown number, some coerce to the zero value, and a client that coerces will silently misinterpret a value a newer server added
• It does not version anything. There is no notion of a schema version, a release, or a compatibility policy. That is what a registry is for

The practical rules that follow are short and worth writing on a wall. Never reuse a field number; mark it reserved instead. Never change a field’s type. Renaming a field is wire-safe and source-breaking, so treat it as a breaking change for your consumers even though the bytes do not care. Always include an explicit zero value in every enum and handle unknown values defensively. This is the same class of discipline covered more broadly in the API versioning and deprecation guide, with the difference that protobuf makes the breakage invisible until it reaches production data.

The load balancing trap

This is the section worth the price of admission, because it costs teams a week each time.

A gRPC client opens an HTTP/2 connection to a server and keeps it. Every subsequent call is a new stream multiplexed over that same connection. That is the efficiency win. It is also the problem: from the perspective of anything operating at the connection level, a client that makes a million calls looks identical to one that makes one.

So if your load balancer is L4, meaning it distributes TCP connections, each client lands on exactly one backend and stays there for the life of the connection. A Kubernetes Service with the default proxy mode is L4. A classic cloud network load balancer is L4. Both will happily “balance” your gRPC traffic by distributing a handful of long-lived connections and then doing nothing for hours.

The symptoms are distinctive. Load is uneven and stays uneven. New pods added by the autoscaler receive no traffic. Restarting clients moves load around, which makes it look like a client bug. Removing a pod causes a load spike somewhere else that never evens out. Under a rolling deploy things briefly look fine, because every client reconnects at once, which is the most misleading possible signal.

There are three real fixes and one common non-fix.

Client-side load balancing. The gRPC client resolves a name to a list of backend addresses, opens a connection to each, and round-robins requests across them itself. In Kubernetes this means a headless service so DNS returns pod IPs rather than a single virtual IP, plus configuring the round robin balancing policy in the client. This is the most efficient answer because there is no extra hop, and it is the most operationally awkward because every client in every language must be configured correctly, and DNS-based endpoint discovery reacts to pod churn only as fast as your resolver refreshes.

An L7 proxy that understands HTTP/2 streams. Put a proxy in the path that terminates the client connection, parses individual streams, and distributes them across its own pool of backend connections. This is what Envoy does, and it is what a service mesh gives you by default. The cost is a hop; the benefit is that balancing, retry, outlier detection and circuit breaking become infrastructure concerns rather than per-language client concerns. For Kubernetes specifically, this is the same reasoning that drives the choices in the Kubernetes gateway guide.

Bounded connection lifetime. Configure the server to send a GOAWAY after a maximum connection age, with a grace period, so clients periodically reconnect and get redistributed. Add jitter or every client in the fleet reconnects simultaneously and you have built a thundering herd. This is a mitigation rather than a fix: it converts permanent imbalance into periodic rebalancing, and it is the cheapest thing you can do today if you cannot change the topology.

The non-fix is adding more replicas. If balancing is broken, more backends means more idle backends.

Needs first-hand data: Deploy the same gRPC service three ways in one cluster, behind a standard L4 service, behind an L7 proxy, and with headless DNS plus client-side round robin, then drive identical load and record per-pod request counts over a full autoscaling event. Publish the coefficient of variation across pods for each. That single chart settles the argument permanently and I have never seen it published with real numbers.

Browser support, and why gRPC-Web is a different protocol

Browsers expose fetch and XMLHttpRequest, neither of which lets JavaScript control HTTP/2 frames or read trailers. gRPC needs both. So gRPC-Web is not gRPC with a smaller client library; it is a distinct wire protocol that encodes the same semantics in a way a browser can produce and consume, with trailers appended to the response body rather than sent as HTTP/2 trailers.

That design forces a translating proxy between the browser and your gRPC service. Envoy’s gRPC-Web filter is the canonical implementation, and several gateways and meshes embed the same capability.

Three consequences are worth knowing before you plan around it. Bidirectional streaming is not available, and client streaming support is limited or absent depending on implementation; server streaming works. The text encoding mode base64-encodes payloads, which inflates them, and you need it if anything in the path cannot pass binary cleanly. And you have added a component to the request path whose failure mode is that your entire web client stops working while your mobile and service-to-service traffic is fine, which is an awkward thing to page on.

The alternative is to adopt a protocol that was designed to work over plain HTTP from the start. The Connect protocol takes that route: a unary call is an ordinary HTTP POST with a JSON or binary body, readable by curl, cacheable by conventional infrastructure, and callable from a browser with no proxy at all, while remaining interoperable with gRPC clients. If the only reason you were going to run a gRPC-Web proxy is browser support, this is worth evaluating before you commit to the proxy.

Schema registries and breaking change detection

Once two teams generate code from the same .proto files, the files themselves become shared infrastructure and need the same treatment as any other shared dependency.

The minimum viable setup is a single repository of .proto files with a lint step and a breaking-change check that compares a proposed change against the committed baseline and fails the pull request. That check must distinguish two kinds of compatibility, and conflating them is a common mistake:

• Wire compatibility. Will bytes serialized by the old schema deserialize correctly under the new one? Renaming a field passes. Reusing a field number fails. This is what protects production data.
• Source compatibility. Will code generated from the old schema still compile against the new one? Renaming a field fails. Adding a field passes. This is what protects your consumers’ builds.

You usually want both checked, with different severities. Wire breakage should be a hard block. Source breakage should be a block for published schemas and a warning for internal ones you can coordinate.

The next level up is a registry that stores versioned schema modules, serves them as dependencies, and generates and publishes client libraries so consumers depend on a versioned artifact rather than on a file path in a shared checkout. That last piece matters more than it sounds: it turns “regenerate your stubs” from a coordination problem into a dependency bump, which is the same benefit described in the SDK generator guide.

Needs first-hand data: Take the last year of .proto changes in your own repository and replay them through a breaking-change checker, classifying each flagged change as a true break, a wire-safe rename, or a false positive. The precision of the checker on your actual change history is what determines whether the team respects the gate or routes around it, and it varies enormously by how the schemas were originally written.

Debugging: reflection is the whole story

The reason you cannot curl a gRPC endpoint is that the client needs the schema to encode the request. Generic clients solve this two ways: you hand them a compiled descriptor set, or the server tells them via the reflection service.

Server reflection is a standard gRPC service that a server can expose, which lets a client ask “what services do you have, and what do their messages look like”. Turn it on and every generic tool below works instantly with no local schema. Turn it off and each tool needs a descriptor file.

It is also, exactly as it sounds, an unauthenticated endpoint that enumerates your entire internal API surface including method names and message structures. On an internal-only service behind a mesh, that is usually acceptable and hugely convenient. On anything reachable from outside a trust boundary, it is free reconnaissance. The common compromise is reflection enabled in development and staging, disabled in production, with descriptor sets published from the registry so operators can still debug production with the same tools.

Buf

Buf is the closest thing this ecosystem has to a complete toolchain. It replaces protoc with a build tool that understands modules and dependencies, adds linting with configurable rule sets, adds breaking-change detection against a baseline, generates code through remote or local plugins, and backs all of it with a hosted schema registry that stores versioned modules and publishes generated SDKs. If your problem is governance rather than runtime, this is the product that addresses it.

Pros

• Breaking-change detection that distinguishes wire compatibility from source compatibility, run as a pull request gate, which is the control that prevents the expensive class of protobuf mistakes
• Dependency management for .proto modules, so importing someone else’s types is a version constraint rather than a vendored copy that silently drifts
• Code generation without a local protoc toolchain or per-language plugin installation, which removes a persistent source of “works on my machine” in polyglot teams
• The registry publishes generated client libraries as normal package-manager artifacts, turning stub regeneration into a dependency bump for consumers

Cons

• The full value is in the hosted registry, so a team that only adopts the open-source CLI gets linting and breaking checks but not the distribution story that justifies the setup
• It imposes opinions about module layout and lint rules that an existing large .proto estate will violate extensively on day one, and the cleanup is real work
• Centralising schema governance creates a new bottleneck if the review policy is stricter than the team’s actual release cadence
• For a single-team service with a handful of .proto files, the toolchain is more machinery than the problem needs

Best for: Organisations where several teams generate code from shared .proto files and a wire-incompatible change reaching production would be expensive.

Pricing: Open-source CLI with no licence cost, plus a hosted registry tier metered on users and hosted modules with enterprise agreements for self-managed deployments.

ConnectRPC

ConnectRPC is a family of libraries implementing the Connect protocol alongside gRPC and gRPC-Web, from the same lineage as Buf. Its central claim is that a unary RPC should be an ordinary HTTP POST with a readable body, so you can curl it, cache it, route it through any proxy, and call it from a browser with no translation layer, while the same server still speaks gRPC to gRPC clients.

Pros

• Removes the gRPC-Web proxy entirely for browser clients, which deletes a component from the request path and the failure mode that comes with it
• A unary call is curl-able and readable, which changes debugging from a tooling exercise into reading a response body
• Servers speak Connect, gRPC and gRPC-Web on the same port, so adoption does not require existing gRPC clients to change
• Plain HTTP semantics mean conventional gateways, CDNs and proxies behave predictably rather than needing HTTP/2-aware configuration

Cons

• Connect is a protocol that this project defines, so choosing it means depending on an ecosystem narrower than gRPC’s, with fewer language implementations
• Streaming support over HTTP/1.1 is constrained, and the full streaming story still needs HTTP/2, so the simplification is real for unary calls and partial elsewhere
• Interoperability with gRPC infrastructure like mesh policies and observability is good but not identical, and edge cases surface in exactly the places you were not looking
• Adopting it is a decision the whole organisation shares, because a service speaking Connect natively pulls its consumers toward Connect clients

Best for: Teams that need browser clients and internal service-to-service RPC from one schema, and want to avoid running a translating proxy to get it.

Pricing: Open source with no vendor and no bill for the libraries and protocol. Your costs are ordinary infrastructure and the engineering time of adoption.

grpcurl

grpcurl is the command-line client for gRPC and it belongs on every machine that touches a gRPC service. Point it at an endpoint with reflection enabled and it lists services, describes methods, and invokes them with JSON that it transcodes into protobuf for you. Point it at a descriptor set and it does the same against a service with reflection off.

Pros

• It is the fastest path from “the service is misbehaving” to a reproducible request, and the invocation pastes cleanly into a ticket or a runbook
• JSON in, JSON out, with the transcoding handled for you, so nobody has to hand-encode protobuf to test a hypothesis
• Works from descriptor sets when reflection is disabled, which is what makes it usable against production services that correctly hide their schema
• Scriptable, so health checks, smoke tests and CI assertions against a real gRPC endpoint are a few lines rather than a test harness

Cons

• One-shot invocations with no session, so exploring an unfamiliar API means retyping long commands rather than navigating
• Constructing deeply nested or repeated messages as inline JSON on a shell command line is unpleasant and error-prone
• Streaming methods are supported but awkward to drive interactively compared to unary calls
• Without reflection you must locate and keep current a descriptor set, which is a small but persistent operational chore

Best for: Anyone debugging or scripting against gRPC services from a terminal, which is to say every engineer on a team that runs them.

Pricing: Open source with no vendor and no bill. There is nothing to buy and nothing to license.

Evans

Evans is an interactive gRPC client: a REPL that connects to a service, lets you browse packages, services and methods, prompts you field by field to build a request, and shows the response. Where grpcurl is the equivalent of curl, Evans is the equivalent of an interactive shell, and the difference matters when you are exploring an API you did not write.

Pros

• Field-by-field prompting removes the worst part of manual gRPC testing, which is hand-constructing a deeply nested message correctly on the first try
• Browsing services and methods interactively makes an unfamiliar API explorable without opening the .proto files
• Keeps connection state and metadata across calls, so authenticated exploratory sessions do not mean re-passing headers on every invocation
• Also offers a non-interactive mode, so a session you worked out interactively can be turned into a scripted call

Cons

• Interactive by design, so it is a poor fit for CI and automation compared to a one-shot client
• Smaller maintainer base and slower release cadence than the mainstream tooling, which is a consideration for something in your debugging critical path
• Depends on reflection or a supplied descriptor set exactly as other generic clients do, so it does not solve the production-schema problem
• Terminal-only, so sharing a reproduction with someone who wants a GUI means translating it anyway

Best for: Engineers exploring an unfamiliar gRPC service by hand, especially when the request messages are deeply nested.

Pricing: Open source with no vendor and no bill.

Postman

Postman added gRPC support to the same workspace that holds your REST and GraphQL collections, which for many teams is the deciding factor: one tool, one place where requests are saved and shared, one set of environment variables and authentication profiles. It imports .proto files or uses server reflection, gives you a request builder with message autocompletion, and supports streaming call types in the UI.

Pros

• gRPC requests live alongside REST and GraphQL in shared collections, so a service’s full surface is documented in one place rather than three tools
• Environments, variables and stored authentication carry across protocols, which removes the credential juggling that makes CLI debugging tedious
• Streaming call types are visible in a UI, which is substantially easier to reason about than streaming in a terminal
• Non-engineers and adjacent teams can exercise a gRPC service without a toolchain, which matters for QA and support workflows

Cons

• A desktop application in the debugging path is heavier than a binary, and the workspace and sync model pulls internal API definitions into a hosted account
• gRPC support has consistently trailed the maturity of the REST experience, and advanced streaming and metadata cases are where the gap shows
• Collection sprawl is a real organisational failure mode, and it applies to gRPC exactly as it does to REST
• Keeping imported .proto definitions current is manual unless you wire it to your registry, which reintroduces the drift problem the registry was supposed to solve

Best for: Teams already standardised on Postman for API work who want gRPC services in the same collections rather than a separate CLI workflow.

Pricing: Free tier for individuals with paid per-user plans adding collaboration, governance and enterprise controls, metered by seat.

Envoy

Envoy is the L7 proxy that most gRPC infrastructure is built on, directly or as the data plane inside a service mesh or gateway. Two capabilities make it central to this list: its gRPC-Web filter translates browser-originated requests into gRPC for upstream services, and its HTTP/2-aware load balancing distributes individual streams across a backend pool, which is the fix for the problem this article opened with.

Pros

• Balances individual HTTP/2 streams rather than connections, which resolves the gRPC load distribution problem at the infrastructure layer for every language at once
• The gRPC-Web filter is the reference translation implementation, so browser support becomes a proxy configuration rather than an application change
• Outlier detection, retries with budgets, circuit breaking and deadline propagation are policy in the proxy instead of per-client code in five languages
• Dynamic configuration through the xDS APIs means routing and load balancing update without restarts, which is what makes it viable as a control-plane data plane

Cons

• The configuration surface is large and unforgiving, and hand-writing it is a specialist skill rather than a task you delegate
• It is a hop in the request path with its own resource footprint, failure modes and upgrade cycle, so you have traded a client library problem for an infrastructure problem
• Most teams should not run it directly but through a mesh or gateway that generates its configuration, which means your real decision is about that layer, not this one
• Debugging a misrouted gRPC call through Envoy requires reading its access logs and stats, which is a distinct skill from debugging the application

Best for: Platform teams that need gRPC load balancing and browser translation solved once at the infrastructure layer rather than in every client library.

Pricing: Open source with no vendor and no bill for the proxy itself. Commercial offerings exist from vendors packaging it as a gateway or mesh control plane, priced separately.

How to choose

These tools are not alternatives to each other. Most gRPC teams end up with something from three of the four groups, so treat this as a checklist rather than a shortlist.

Do you need browser clients? If yes, decide between a gRPC-Web proxy and adopting Connect before you write the first service, because retrofitting is harder than choosing. If your only browser need is unary calls, Connect removes a whole component from your topology. If you need server streaming to browsers and already run Envoy, the filter is already there.

How many teams change .proto files? One team, and a lint step plus a breaking-change check in CI is sufficient, which the Buf CLI gives you with no registry. Several teams, and you want a registry with versioned modules and published SDKs, or you will spend the next year coordinating regeneration by hand.

Where does load balancing happen? Answer this explicitly on a diagram before launch. If the answer is “the Kubernetes service”, you have the problem described above and do not know it yet. Pick client-side balancing with a headless service or an L7 proxy, and set a bounded maximum connection age either way so that a rebalance is always eventually possible.

Is reflection on in production? Decide, write it down, and make sure the debugging tools your on-call uses work under whichever answer you chose. Finding out at three in the morning that grpcurl needs a descriptor set you do not have is an avoidable incident.

Tool	Layer	Solves	Picks itself when
gRPC	(standard, not a product)	The RPC protocol itself	It is the thing you are adopting, not a choice among options
Protocol Buffers	(standard, not a product)	Schema and wire format	Same; the choice is how you govern it
Buf	Toolchain and registry	Governance, breaking changes, SDK distribution	More than one team edits shared .proto files
ConnectRPC	Protocol and libraries	Browser support without a proxy, curl-able calls	Web clients matter and you want one server to serve both
grpcurl	CLI client	Scriptable debugging and smoke tests	Always; install it on day one
Evans	Interactive client	Exploring unfamiliar services, nested messages	Building complex requests by hand is the bottleneck
Postman	GUI workspace	Shared collections across protocols	The team already lives in Postman for REST
Envoy	L7 proxy	Stream-level balancing, gRPC-Web translation	Balancing and browser translation belong in infrastructure

Frequently asked questions

Why is my gRPC load unbalanced even though my load balancer is healthy?

Because it is almost certainly balancing connections, not requests. gRPC keeps one HTTP/2 connection per client and multiplexes every call over it, so an L4 balancer distributes a handful of connections once and then has nothing left to do. Move balancing to an L7 proxy, switch to client-side round robin over a headless service, or at minimum set a bounded maximum connection age with jitter so clients periodically redistribute.

Can I call a gRPC service directly from browser JavaScript?

No. Browsers do not expose the HTTP/2 frame control and trailer access that gRPC requires. Your options are a gRPC-Web proxy translating on the way in, accepting that bidirectional streaming is unavailable, or a protocol like Connect that is designed to work over ordinary HTTP from the browser without a proxy.

Should server reflection be enabled in production?

Default to no for anything reachable outside your trust boundary, and yes for internal services where the debugging convenience is worth more than the schema disclosure. If you disable it, publish descriptor sets from your registry so grpcurl and Evans still work, and make sure that path is documented in the runbook before the first production incident.

Is renaming a protobuf field a breaking change?

On the wire, no: the field number carries the identity and the bytes are unaffected. In generated code, yes, and every consumer’s build breaks on the next regeneration. Treat it as breaking, because your consumers experience it as breaking. Reusing a field number is the opposite and far more dangerous: it compiles cleanly everywhere and silently misinterprets stored data.

Should I use gRPC for a public-facing API?

Rarely. Public consumers need browser support, human-readable traffic, ordinary HTTP tooling and a low barrier to a first successful call, and gRPC is weaker on all four. The common shape is gRPC internally where efficiency and streaming pay off, with REST or Connect at the public edge, which is also where the gateway and API management layer lives.

Related reading

• Best API management platforms — the control plane layer around the gateway that fronts your gRPC services.
• Best API gateways for Kubernetes — where L7 gRPC balancing gets solved in a cluster.
• Best SDK and API client generators — publishing generated clients as versioned artifacts rather than shared checkouts.
• Best tools for API versioning and deprecation — the compatibility discipline protobuf enforces at the wire and not at the source.
• Best API testing tools — exercising gRPC alongside REST in the same suites.
• Best GraphQL servers and platforms — the other non-REST option, with a very different set of tradeoffs.