Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The reason to use Protobuf is not performance

buf.build

Post reply on HN
Print view View original

21–23 of 23 posts

Re: The reason to use Protobuf is not performance

#21

Post by BerislavLopac »

theamk wrote: post #2

schema-driven development is great, but I wish people spent more time on JSON-based API schema rather than switch to protobuf. Because protobufs immediately require some minimal level of complexity (at least a build system!) and thus effectively block small one-off scripts. And the debuggability is also not great. Can we (as an industry) pick a standard (openapi? jsonschema? something else?) and add the tooling to ma…

> pick a standard (openapi? jsonschema? something else?)

This is a false dichotomy, as OpenAPI and JSON Schema are complementary: as of version 3.1, OpenAPI use JSON Schema to describe request and response payload content (prior to that version it was almost compatible).

They describe different things: OpenAPI describes the request-response API model, while JSON Schema can be used to specify contents of any JSON-encoded data -- for example in streaming messages or document databases.

There is also AsyncAPI, which is designed to document and specify the event-based API, for example in a system using Apache Kafka or a similar queue to communicate.

Re: The reason to use Protobuf is not performance

#22

Post by neilalexander »

ath3nd wrote: post #20

Protobuf is great, but wait till you hear about JSON! Jokes aside, while JSON is bulkier, binary protocols like protobuf, avro, thrift have one big penalty: they are hard to read/understand by humans without some tooling. The value of seeing the network call and being able to actually understand what's going on without having to translate the format into something human readable is hard to overstate. The bigger paylo…

Until you have to put some binary data in the JSON of course, at which point most of the supposed benefits of JSON go right out the window.

Re: The reason to use Protobuf is not performance

#23

Post by ath3nd »

neilalexander wrote: post #22
ath3nd wrote: post #20

Protobuf is great, but wait till you hear about JSON! Jokes aside, while JSON is bulkier, binary protocols like protobuf, avro, thrift have one big penalty: they are hard to read/understand by humans without some tooling. The value of seeing the network call and being able to actually understand what's going on without having to translate the format into something human readable is hard to overstate. The bigger paylo…

Until you have to put some binary data in the JSON of course, at which point most of the supposed benefits of JSON go right out the window.

For structured binary data, protobuf is, of course, probably a better fit than JSON.

However, I don't think structured BINARY data is encountered as often on the interwebs as JUST structured data, and simpler textual formats like JSON, XML (and even csv) shine here, despite their shortcomings in terms of message size.

As for unstructured (or loosely structured) binary data like videos or large binaries (binary blobs is what I am talkin about), protobuf is as much as a poor choice as any other structured/schema based data protocols.

Protobuf has no tremendous benefit to any of the other binary formats like avro either, so I don't see why I should be excited about it. I wish google and the google ecosystem people stop trying to make it sound like THEIR simple schema based binary protocol is a big deal and try to shove it down our throats. For simple message passing around, I intend to keep choosing compressed JSON for the foreseeable future, regardless of what narrative some fan article is peddling.

Post reply on HN