[gravypod]

Imagine this offering: "Why go through the hassle of generating clients for your service for each language when we can build ergonomic clients automatically" and "Why manually look for breaking changes in your API when we can detect them manually" or "We can give you $AMAZING_FEATURE for free by using a clearer language to describe your api" where your feature could be:

1. Reduced bandwidth ingress 2. Automatic tracing of PII through your system 3. Developer-controlled ops stuff (annotating an RPC as cachable, etc) 4. Automated tracing instrumentation 5. Message streaming (gRPC streams are amazing)

I can think of a whole host of features that can be built off of protos (I've even built ORMs off of protobuffs for simple things [0]). The value prop is there IMO. HTTP + json APIs are a local minima. The biggest concerns "I want to be able to view the data that is being sent back and forth" is a tooling consideration (curl ... isn't showing you the voltages from the physical layer, it is decoded). Buff is building that tooling.

[0] - https://github.com/CaperAi/pronto

[selfhoster11]

> Why manually look for breaking changes in your API when we can detect them manually

You can't detect all breaking changes automatically. A field can subtly shift semantics on an API level, yet that breaks a workflow for some downstream consumer somewhere.

OpenAPI and other API description languages give a clear an unambiguous description of an API that can auto-generate clients just fine. Binary JSON/gzipped JSON is frequently very space efficient too. I'm happy to grant the rest of your points, but I cannot see that much value here from an SME perspective. Using tracing and other advanced techniques require the right knowledge to use, and I don't think it's that common in smaller orgs.

[gravypod]

> You can't detect all breaking changes automatically. A field can subtly shift semantics on an API level, yet that breaks a workflow for some downstream consumer somewhere.

That is what aip.dev helps with. Following these style guides makes it hard to have ambiguous meaning of a field in an API. Linting APIs is something buff provides.

This isn't a "catch 100%" thing but this is more close to a "catch >XX% of mistakes" which is good enough if it cheap.

> OpenAPI and other API description languages give a clear an unambiguous description of an API that can auto-generate clients just fine.

The last time I used OpenAPI it was very verbose. It wasn't anything like writing code (something I am good at). It was more like writing a large config (something I'm bad at). Protos provide a code-like view on APIs. This is just preference though but I like it.

> Binary JSON/gzipped JSON is frequently very space efficient too.

My assumption is that parsing JSON will require more CPU than protos and much more than flatbuffers. More so when you factor in gzip.

> Using tracing and other advanced techniques require the right knowledge to use, and I don't think it's that common in smaller orgs.

Taking something that's complex and making it easy for people to use sounds like a business prop. Is tracing something people don't do because there's no value or because it's hard to use?

Basically: you don't want to use protos for any one reason. It's a whole ecosystem that makes many things magically better.

[BerislavLopac]

These are all good effects of SDD (schema/spec driven development); but there is nothing in ProtoBufs that make them intrinsically better then other solutions like OpenAPI/JsonSchemas and others.