I too was using PBs a lot, as they are quite popular in the Go world. But i came to the conclusion that they and gRPC are more trouble than they are worth. I switched to JSON, HTTP "REST" and websockets, if i need streaming, and am as happy as i could be.

I get the api interoperability between various languages when one wants to build a client with strict schema but in reality, this is more of a theory than real life.

In essence, anyone who subscribes to YAGNI understands that PB and gRPC are a big no-no.

PS: if you need binary format, just use cbor or msgpack. Otherwise the beauty of json is that it human-readable and easily parseable, so even if you lack access to the original schema, you can still EASILY process the data and UNDERSTAND it as well.

▲

tombert 6 days ago | parent [-]

I am very partial to msgpack. It has routinely met or exceeded my performance needs and doesn’t depend on weird code generation, and is super easy to set up.

Something that I don’t see talked about much with msgpack, but I think is cool: if your project doesn’t span across multiple languages, you can actually embed those language semantics into your encoder with extensions.

For example, in Clojure’s port of msgpack out of the box, you can use Clojure keywords out of the box and it will parse correctly without issue. You also can have it work with sets.

Obviously you could define some kind of mapping yourself and use any binary format to do this, ultimately the [en|de]coder is just using regular msgpack constructs behind the scenes, but i have always had to do that manually while with msgpack it seems like the libraries readily embrace it.

	▲	gethly 6 days ago \| parent [-]
		Indeed, the support is widespread across languages. OTOH, using compression, like basic gzip, for http responses, turns the text format into binary format and with http2 or http3 there is no overhead like it would be with http1. so in the end the binary aspect of these encoders might be obsolete for this use case, as long as one uses compression.