Picking Between REST, GraphQL, and gRPC for a New Service

REST is good at being understood by anyone, cached by ordinary HTTP infrastructure, and debugged with nothing more than a browser or curl. That's why it remains the default for public APIs and anything a third party will integrate against.

GraphQL is good at letting a frontend ask for exactly the fields it needs across several resources in one round trip, which matters most when your client is a mobile app on a slow connection or a dashboard that renders dozens of small widgets. gRPC is good at low overhead, strongly typed contracts, and streaming, which is why it dominates service-to-service calls inside a single infrastructure.

GraphQL's flexibility on the client side pushes a real cost onto the server: a query that asks for a list of orders and each order's customer can trigger one database call per order if your resolvers aren't written carefully, the classic N+1 pattern. GraphQL itself doesn't prevent this. A batching layer, typically a dataloader pattern that groups requests within a single tick, does.

Skipping that layer is the most common reason a GraphQL API that performs fine in development falls over under real traffic, because the query shapes that expose the problem are exactly the ones a flexible schema invites clients to write.

gRPC's binary protocol and generated clients cut serialization overhead and give you a contract that breaks the build instead of breaking in production when a field changes type. That advantage matters most at high call volume between services you control, where shaving overhead per call adds up.

It matters far less for a handful of calls a minute, or for anything a browser needs to call directly, since browser support for gRPC is limited without a proxying layer. Reaching for gRPC because it's fast, for a service that makes a few dozen calls a day, adds tooling cost without a real payoff.

The generated client and server stubs are the part teams underestimate. They remove an entire class of bug where one side of a call changes a field's meaning without the other side noticing, but they also mean every schema change needs a code generation step wired into your build, which is one more thing that can be misconfigured on a new engineer's first day.

Ask who the caller is first. A third party or a public integration points to REST. A frontend that needs to shape its own queries across nested resources points to GraphQL. A service calling another service you both control, especially with high volume or a need for streaming, points to gRPC.

REST, GraphQL, and gRPC all support the same on-demand deployment habits that put a team in DORA's highest-performing cluster, but only if your contracts don't break every time a client updates¹. Whichever protocol you choose, versioning discipline matters more to your deploy cadence than the protocol itself does.

Match the protocol to the caller like this:

• Pick REST when the caller is a third party or a public integration, since it is widely understood and works with ordinary HTTP caching.
• Pick GraphQL when a frontend needs to ask for exactly the fields it wants across several resources in one round trip.
• Pick gRPC when one service calls another that you control, especially with high volume or a need for streaming.
• Expect to run more than one protocol, with a gateway translating between them at the edge.

Internal flexibility gets harder to justify once a contract has customers outside your own team depending on it. A GraphQL schema that a partner queries in unexpected ways becomes something you can't casually restructure. A gRPC contract with an external partner requires them to regenerate clients on your schedule, not theirs. REST's looser contract, ironically, is often the easiest one to evolve without breaking someone you don't control.

This is also where deprecation policy starts to matter as much as the protocol choice itself. A field you remove from an internal gRPC contract is a same-day fix across your own services. The same removal on a public REST or GraphQL API needs an announced sunset window, because you can't force an external integrator to redeploy on your timeline.