REST, GraphQL, or gRPC: Choosing by Workload

REST's biggest advantage is how well understood it is: every client library, every proxy, every piece of infrastructure already knows how to cache a GET request and respect an HTTP status code. Versioning by URL path is simple to reason about, and debugging with a browser or curl needs no special tooling.

Its weak point is shape mismatch. A mobile client that only needs three fields still gets the whole object back, and a client that needs data from three different resources has to make three round trips or accept a bespoke aggregation endpoint.

GraphQL lets a client ask for exactly the fields it needs across multiple resources in one request, which is genuinely useful for a mobile app pulling data from several backend services at once. The tradeoff shows up on the server: a naive resolver-per-field implementation triggers a separate database query for every item in a list, the classic N plus one pattern, unless you add batching, typically a dataloader-style cache that groups those lookups together within a single request.

A single GraphQL endpoint also makes HTTP-level caching harder, since every request is technically a POST to the same URL; you end up caching at the application layer instead.

gRPC's binary protobuf encoding and HTTP/2 streaming make it a strong fit for service-to-service calls inside your own infrastructure, where you control both ends and latency actually matters. Contracts are strongly typed and generated from a schema, which catches a lot of integration mistakes at compile time instead of in production.

What it isn't is a drop-in public API protocol. A browser can't call gRPC directly without a gRPC-Web proxy translating the calls, and debugging a binary payload with plain tooling is harder than reading a JSON body.

• A public API with client needs you can't fully predict: REST with solid pagination and clear versioning.
• One client, mobile or web, pulling nested data from many backend services: GraphQL with resolver batching in place from day one.
• Calls between services you control, where latency and type safety matter more than human readability: gRPC.
• You don't have to pick just one for the whole company. REST at the public edge and gRPC between your own services is a normal, common combination.

Rewriting an entire working REST API into GraphQL in one pass, instead of adding a GraphQL gateway in front of the existing services and migrating client by client, turns a manageable project into a risky one. Adopting gRPC for a public-facing API before checking whether your actual client base can call it is a similar trap. And letting a GraphQL schema grow without any deprecation discipline means every field you ever shipped is effectively supported forever, because nothing ever tells clients to stop using it.

REST typically versions by URL path or a header, giving old clients a stable target to keep calling while new ones move on; the cost is maintaining more than one version of the same endpoint in parallel. GraphQL takes a different approach: fields get marked deprecated with a note on what replaces them, and clients migrate field by field instead of the whole schema jumping versions at once, which only works if someone actually tracks which clients still call the deprecated fields.

gRPC leans on its schema definition for this: adding a new field is safe, but removing or renaming one breaks every client still compiled against the old contract, so changes there need the same discipline as a public REST version bump, just enforced by the compiler instead of by convention.