[bairen]

We built a backend heavily using protobufs/grpc and I highly regret it.

It ads an extra layer of complexity most people don't need.

You need to compile the protobufs and update all services that use them.

It's extra software for security scans.

Regular old http 1 rest calls should be the default.

If you are having scaling problem only then should you consider moving to grpc.

And even then I would first consider other simpler options.

[ants_everywhere]

Personally I'll never go back to REST because you lose important typing information. The complexity doesn't go away. In the RPC/codegen paradigm the complexity is in the tooling and is handled by machines. In REST, it's in the minds of your programmers and gets sprinkled throughout the code.

> You need to compile the protobufs and update all services that use them.

You need to update all the services when you change your REST API too right? At least protobufs generates your code automatically for you, and it can do it as part of your build process as soon as you change your proto. Changes are backwards compatible so you don't even need to change your services until they need to change.

[bairen]

Its silly to think protobufs code gen is a advantage. I can take a json object/xml/csv from any API and plug it into a website that will spit out models in any language I want.

The only real advantage of grpc and protobufs have are speed and reduced data transmission.

And hey fair enough man if those are your bottle necks.

[throwbadubadu]

Sounds really like you used them for the wrong use case. If you are in need of a binary compact serialization, they are not prefect (is there any) but fair enough.

[bairen]

We ended up wrapping them in envoy so that our UI can convert the grpc to regular old http 1. And that's where they get the most use.

And by doing that we've added extra layers and it ended up slower than it would have been had we just used regular rest.

Further more now we need to keep evoy up to date.

Occasionally they break their API on major versions. Their config files are complicated and confusing.

So, imo, grpc should only be used for service to service communication where you don't want to share the code with a UI and speed and throughput is very very important.

And speed of http 1 rarely is the bottleneck.

[Ferret7446]

You don't need to compile the protobufs. The alternative, for all serialization formats, is to either load the schema dynamically, or write the handling logic manually yourself (or write your own generator/compiler).

gRPC supports HTTPv1 and can be mapped to a RESTful API (e.g. https://google.aip.dev/131).