gRPC, GraphQL, or REST: What Actually Breaks Each One at Scale

REST's strength is that almost every engineer, tool, and piece of infrastructure already understands it, from browser caching to a load balancer's health check. Its failure mode at scale is usually over-fetching, a mobile client pulling a full user object to display a name and avatar, and versioning drift, where v1 and v2 of an endpoint diverge slowly until nobody is confident which clients depend on which behavior. Neither problem is fatal, but both accumulate quietly and show up as a slow API and a migration nobody wants to own.

GraphQL directly solves REST's over-fetching problem by letting the client ask for exactly the fields it needs, and it genuinely improves mobile client performance on variable networks. What it takes away is the free HTTP caching that REST gets from URLs mapping cleanly to resources, since every query can be a different shape at the same endpoint. Teams that adopt GraphQL without also solving caching, either through a normalized client cache or persisted queries with response caching at the edge, often end up with more total database load than the REST API it replaced.

gRPC's binary protocol and generated client code give it real latency and payload-size advantages for service-to-service calls inside your own infrastructure, and its strict schema catches a whole class of contract-mismatch bugs at compile time that REST only catches at runtime. It is a poor fit for a public-facing API, since browser support is limited without a proxy layer like grpc-web, and the tooling ecosystem for external partners is much thinner than REST's. Most teams that use gRPC well use it internally, between their own services, and keep a REST or GraphQL layer facing the outside world.

Match the protocol to who is calling it. A public API consumed by partners you don't control, and that benefits from HTTP caching and broad tooling support, points toward REST. A single-page or mobile client fetching deeply nested, variably-shaped data points toward GraphQL, provided you plan the caching layer up front rather than after the database load spikes. High-throughput internal service-to-service calls, where both ends are your own code and latency matters, point toward gRPC. Many production systems that outgrow a single protocol end up running two of the three, one per surface, rather than forcing a single choice everywhere.

Match the protocol to the caller with these checks:

• Choose REST for public partner APIs where HTTP caching, broad tooling support, and callers you don't control matter more than fine-grained field selection.
• Choose GraphQL for single-page or mobile clients fetching deeply nested, variably shaped data, but plan query limits and a caching layer before launch.
• Choose gRPC for high-throughput service-to-service calls inside your own infrastructure, where strict schemas and binary payloads pay off and browser support is not needed.
• Avoid gRPC for public-facing APIs unless you are willing to run a proxy layer, since browser support is limited without one.

REST demands discipline around versioning and deprecation, since nothing forces you to keep an old version alive, and skipping that discipline is how partners get broken silently. GraphQL demands a real plan for query complexity limits and caching before launch, since an unbounded, deeply nested query can be trivially abused to overload the database in a way a REST endpoint's fixed shape cannot. gRPC demands comfort with generated code and protobuf schema evolution rules, since a careless field change can break backward compatibility in a way that is easy to catch in gRPC's tooling but easy to miss if the team isn't used to reading it.

Imagine a team that migrates its mobile API from REST to GraphQL specifically to fix over-fetching on a slow cellular connection, ships it, and then watches database load climb rather than fall. The mobile client got faster, but nobody added query depth limits or a caching layer, so a single screen that used to trigger one cacheable REST call now triggers a fresh, uncached, deeply nested query every time it renders. The lesson isn't that GraphQL was the wrong choice, it's that the caching and complexity-limiting work is not optional scaffolding you can add later; it is the part of the migration that actually determines whether the tradeoff pays off.