[thinkharderdev]

> The worst part of all is that most people don’t need gRPC, but use it anyway. It’s a net addition of complexity and you’re very likely not getting the actual benefits. I’ve seen countless simple REST APIs built with language-native tooling burned to the ground to be replaced with layers of gRPC trash that requires learning multiple new tools and DSLs, is harder to troubleshoot and debug, and ultimately tends to force API rigidity far sooner than is healthy.

This sounds odd to me because I don't really see how gRPC would cause any of those issues?

> layers of gRPC trash

What layers? Switching from REST (presumably JSON over http) to gRPC shouldn't introduce any new "layers". It's replacing one style of API call with a different one.

> learning multiple new tools and DSLs

New tools sure, you need protoc or buf to build the bindings from the IDL, but what is the new DSL you need to learn?

> ultimately tends to force API rigidity far sooner than is healthy

How does gRPC force API rigidity? It is specifically designed to be evolvable (sometimes to its usability detriment IMO)

There are some definite footguns with gRPC and I am becoming increasingly annoyed with Protobuf in particular as the years go on, but going back to REST APIs still seems like a huge step backwards to me. With gRPC you get a workflow that starts with a well-defined interface and all the language bindings client/server stubs are generated from that with almost zero effort. You can kind of/sort of do that with REST APIs using openapi specs but in my experience it just doesn't work that well and language support is sorely lacking.

[arp242]

> What layers? Switching from REST (presumably JSON over http) to gRPC shouldn't introduce any new "layers".

Of course it does, starting with the protobufs and code generation. You say yourself in your very next reply:

"New tools sure, you need protoc or buf to build the bindings from the IDL, but what is the new DSL you need to learn?"

And the DSL is presumably protobuf, which you yourself are "increasingly annoyed" with.

[thinkharderdev]

You need all the same stuff with a REST API only instead of using tooling to codegen all the boilerplate you have to write it by hand (or use janky OpenAPI code generators which, in my experience, rarely work very well).

I am increasingly annoyed by protobuf as a standalone format but given the choice to create a new API using gRPC (where I can spend five minutes writing some proto files and then codegen all the boilerplate I need for both server and client in any mainstream language) and creating it as a REST API where I have to manually code all the boilerplate and decide between a zillion different ways of doing everything I will choose gRPC 100% of the time.

[arp242]

> You need all the same stuff with a REST API

That's just not true. A straightforward REST API is significantly simpler and less code throughout.

[thinkharderdev]

How exactly? If we take the simplest possible "hello world" service, then protoc generates all the code for a gRPC service without you having to manually type anything