I use it because: 1. I am not writing a network API without a solid spec, and 2. I want to decouple the number of tcp connections from the amount of pending work. I don't want one wonky msg to consume many resources and I want a spike of traffic to cause more msgs to be sent to the worker pools not cause a bunch of TCP connection establishment, SSL handshakes, etc. I also find it personally offensive to send field names in each network msg, as per JSON or XML.

This, 100%. I am never going back to stringly typed JSON in whatever random url structure that team felt like doing that week. GraphQL is made for Facebook type graph problems. Its way overcomplicated for most use cases. I just want a lingua franca DSL to enforce my API specification in a consistent manner. I dont care if its PUT POST PATCH. Just keep it easy to automate tooling.

> People use it - like I do - because they like the improved type safety compared to REST.

You don't need a binary format just to get type safety. JSONSchema, OpenAPI, etc exist after all.

> But in this case the DSL is OpenAPI, which is an error prone mess of YAML or JSON specifications.

They might not be pretty, but they're not particularly error prone (the specs themselves are statically checked).

YAML in any form is error prone and hard to write. Protobuf - for all its warts - is much easier to write And much more type safe.

But let’s just agree to disagree here. You do you and build REST APIs, while I’ll stick to gRPC

I’m not anti-protobuf; it’s just overkill for type safety. But yeah, use what you want.