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: th

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 payload size of JSON is not enough for me not to see the main benefit : I can check what's going on with any tool: from curl, to postman, to my browser's damn network window. With some compression, JSON is not that bad size wise either. To read and generate protobuf, you mostly have to rely on some tooling/library provided by Google, and those, like most of their software (looking at you, Guava), is the reverse of backwards compatible, despite what they're advertising. Just search Google for "protobuf version mismatch". Maybe I am speaking heresy here, but software by Google (like k8s, protobuf, guava, etc) for me has been notoriously backwards incompatible and overly complex, and I try to steer clear from it as much as possible. I gotta give the crown to K8s here, it specifically is an absolute clusterfuck, the pinnacle of what happens when 1000s of good ideas are combined together in a sloppy, quick execution and without regard for previous versions. You can achieve schema with any other binary format like avro (which doesn't tie you to using google libraries, which i hate with a passion), and you can achieve a schema with xml and json, so after reading the article, there is still 0 reason for me to use protobuf, if not for performance and only within a google ecosystem.