Hacker News Reader

Comment by ForHackernews | Hacker News Reader

> That params is nothing more than just base64 encoded protobuf, which is a common encoding format used throughout Google.

Pour one out for the google dev in charge of b64 encoding their fancy binary message format so it can be jammed inside a JSON blob. If you want a vision of the future, imagine a boot with "worse is better" imprinted on the sole stomping on an engineer's face, forever.

View on HN

It's everywhere and it's the worst. I sometimes ponder whether or not the volume of protobuf bytes represented as b64 encoded protobuf in JSON exceeds that of actual protobuf bytes sent over the wires of the internet, and then I pour one out for myself.

JSON's not even that bad if it's gzipped! It compresses relatively well.

If only there were some way to easily send this binary gzip data to this API that accepts JSON...

Internally, it would be a b64 protobuf in a protobuf field.

The json part is an automatic conversion.

Why would it be b64 encoded? There's nothing that prevents you from putting an encoded protobuf into a protobuf as `bytes` type. `bytes nestedMessage = 42;` Only delimited message formats like JSON or XML need to encapsulate messages before nesting.

Because it is in a Json? Internally it probably is protobuf with bytes.

But the external API is Json and so it needs to be converted at some point.

https://stackoverflow.com/questions/49358526/protobuf-messag...

Huh?

Internally, it is (maybe) a binary field of a protobuf.

Then when translating to JSON, it was converted to a string via base64 encoding.

JSON string of base64 encoded protocol buffer...you don't need to know what company did that to know what company did that.

Reply on news.ycombinator.com