gRPC's compiled contracts catch microservice breaks that REST lets slip through

The failure mode gRPC targets

A developer posting on dev.to — the piece was first published on the author's own site, juanchi.dev — opens with a scenario many microservice shops will recognize: fifteen services, each exposing its own REST API with its own JSON naming conventions, Swagger documentation that goes stale, and HTTP clients either written by hand or loosely generated from OpenAPI. In that setup, according to the post, a field change in the payments service is discovered by three downstream teams only when production fails. Layer on service-to-service traffic at ten thousand calls per second and the overhead of JSON over HTTP/1.1 starts showing up in the infrastructure bill. The author's argument is that gRPC exists precisely for this pain: Google built it for internal inter-service communication before releasing it as open source, and it is a poor fit for anything much smaller.

Contracts that compile

gRPC is a remote procedure call framework that runs on HTTP/2 and uses Protocol Buffers as its default serialization. Instead of publishing endpoints and letting each client assemble its own requests, a team writes a .proto file declaring a service and its messages, and the protobuf compiler (protoc) generates serialization classes plus client and server stubs in Go, Java, Python, C++ or Node from that single definition. The author, whose background is in Java, compares the arrangement to SOAP with WSDL — typed, versionable contracts — but without XML's baggage and with better performance. The post walks through a small orders service in proto3 and a Java implementation extending a generated base class, with no JSON anywhere: payloads travel as binary. The practical payoff is that field names and types are enforced by generated code rather than by documentation someone forgot to update — an incompatible change becomes a build failure instead of a production incident.

Speed claims, stated with varying confidence

Two versions of the post appeared on dev.to within seconds of each other, one in Spanish and one in English, and they diverge slightly in how firmly they state the performance case. Both credit HTTP/2 for multiplexing requests over a single TCP connection, native bidirectional streaming and header compression — the structural reasons gRPC tends to beat REST plus HTTP/1.1 under heavy load. The Spanish original, though, explicitly declines to present this as a measured result, describing it as a design advantage documented by the gRPC project rather than a benchmark the author ran; the English version drops that caveat. For JVM teams, the author points to grpc-spring-boot-starter as established Spring Boot support.

When it is the wrong tool

The post spends as much effort on anti-cases as on the pitch. Protobuf and the async streaming model differ from familiar request/response thinking, and the author calls the ramp-up genuine friction rather than an afternoon of reading, without putting a number on it since it depends on the team. Debugging is more tedious because curl cannot call a gRPC endpoint; inspecting traffic requires tools such as grpcurl or BloomRPC. Browser clients need gRPC-Web plus an intermediate proxy, another layer of complexity. Public APIs consumed by third parties with no control over their stack remain friendlier as REST with OpenAPI. And a system of two or three low-traffic services is likely taking on complexity it does not need — the author recommends staying with REST there, or considering tRPC in a TypeScript monorepo.

Why it matters

The piece reads less like advocacy than a decision procedure. Its central claim generalizes beyond gRPC: as the number of services and teams grows, the dominant risk is not any single endpoint but the absence of an enforced agreement between services. Making the contract something a compiler checks moves a whole class of integration failures from runtime to build time. The price is explicit — a learning curve, a weaker browser story, harder debugging — and the author's conclusion is that the trade only pays when the underlying problem is actually present: heavy inter-service traffic, a real need for strong contracts, and a team prepared for the entry cost. Community validation, the author notes, tells you a tool is proven, not that your team is ready for it.