tech moves fast. every year there’s a new tool, protocol, or framework that claims to be “better” than the old stuff. grpc is one of those things that sounds amazing on paper, and sometimes it really is. faster than rest, smaller payloads, supports streaming, strongly typed, all that good stuff.

but just because something is technically better doesn’t mean it’s the right choice for everything.

grpc is powerful, but it also comes with tradeoffs. in some cases, using it will actually make your life harder. let’s talk about when grpc isn’t the right tool and why rest might still win.

1. your api needs to work in the browser

this is the first big blocker.

grpc uses http/2 and binary data (via protobuf). most browsers don’t fully support this natively. if you're building an api that’s supposed to be called directly from the frontend, like a single-page app in react or vue, grpc becomes a problem.

you’ll need grpc-web, which is basically a wrapper around grpc that translates it into something the browser can use. but now you need a proxy layer like envoy, some extra setup, and more complexity than you probably wanted.

with rest, your frontend can just call fetch("/api/data") and move on with life.

2. you don’t actually need the performance gains

yes, grpc is fast, especially for internal microservice calls. but ask yourself, do you need that speed right now?

for most apps, latency isn’t coming from your json payloads or the lack of streaming. it's from database queries, cache misses, bad indexing, or just general logic bloat.

rest is “slow” only when you’re pushing it too far. for most use cases like user auth, dashboards, admin tools, rest is fast enough and way easier to work with.

3. tooling is more annoying than you think

to use grpc, you need to define services and messages using .proto files, generate client and server code, and make sure both ends are in sync. the contract enforcement is great, but it’s also a lot of boilerplate.

with rest, you can just spin up an express server or a flask route and be done in five minutes. want to call it from the frontend? just open postman or use curl. done.

grpc isn’t that simple. you need the right grpc client library, generated code, and maybe even special build steps.

4. your team isn’t ready for it

not every team is familiar with protobufs, grpc tooling, or debugging streaming apis. jumping into grpc without experience can slow you down quickly.

debugging a rest call is easy. open devtools, see the request, check the json. debugging grpc? not so fun. you often can’t even read the request body without special tools.

if your team knows rest and it’s working fine, adding grpc just because it sounds cooler might not be worth it.

5. rest is way easier to test and mock

this is a big one.

when you’re testing rest endpoints, you can easily mock requests using tools like msw, nock, or just by faking axios or fetch.

grpc mocking is possible, but the tooling is more complex. you often need to mock entire services, implement fake clients, or deal with streaming behavior. again, more boilerplate.

if testing is a big part of your workflow, which it should be, grpc can make things messier unless you’re really invested in setting it up right.

6. you don’t need streaming

grpc supports bidirectional streaming, which is genuinely awesome for real-time stuff like chat, live dashboards, or telemetry.

but let’s be honest, how often do you actually need that?

most apis are still request and response. rest handles that model just fine. you don’t need grpc’s streaming unless your app is doing something real-time.

7. infra gets complicated

grpc needs http/2. and while modern infrastructure supports that, it’s not always plug-and-play. some load balancers and proxies don’t work well with grpc out of the box. you might need to add envoy or configure nginx in a special way.

rest just works. anywhere. local dev, prod, staging, your laptop, even a raspberry pi.

so when is grpc actually a good idea?

grpc shines when:

  • you’re doing internal service-to-service communication
  • performance really matters
  • you want strongly typed contracts between services
  • you’re dealing with high-frequency, structured data
  • you need real-time streaming

if that sounds like your app, grpc might be a good fit.

but if you’re building:

  • public apis
  • frontend-backend apis
  • admin dashboards
  • typical web or mobile apps

then rest is probably the simpler and more flexible option.

closing thoughts

grpc is great, but it’s not magic. and it’s definitely not better than rest in every situation. like most things in software, it depends.

use the right tool for the job. not the newest, not the most hyped, just the one that makes sense for your app, your team, and your users.

rest isn’t dead. grpc isn’t perfect. and you don’t get extra points for using the fancier thing if it slows you down.