4 ms·

As always, each protocol/data format has it's place. You need to maximize the amount of data you send in each packet? Then protobuf is better than JSON. Need to

As always, each protocol/data format has it's place. You need to maximize the amount of data you send in each packet? Then protobuf is better than JSON. Need to support large amount of clients without any fuzz? Then JSON is better. Wanna pass around data you don't know the schema of? JSON again. Contexts matters, there is no silver bullets, everything has trade offs and so on, and so on.

ninepoints 4y ago
Honestly, gzipped json is likely much smaller than uncompressed protobuf. If you were going to use a binary protocol, why choose one that has no partial parsing/toc these days. There are much better alternatives IMO (flatbuffers being one of them)
- oll3 4y ago
  > Honestly, gzipped json is likely much smaller than uncompressed protobuf. Likely not. See here for a comparison: https://nilsmagnus.github.io/post/proto-json-sizes/ https://nilsmagnus.github.io/post/proto-json-sizes/ Btw, binary formats can also be compressed though it typically won't yield the same compression ratio as similar json would since there will be less repeation in the binary format.
  - ninepoints 4y ago
    Or, we could have done a comparison with large strings and see the opposite result. Silly benchmark is silly (or should I say, specific)
speedgoose 4y ago
JSON messages in a compressed websocket stream are surprisingly tiny. Bigger than compressed protobuf packets but not by much, and much smaller than uncompressed protobuf packets.
- capableweb 4y ago
  Yeah, which is probably fine in most cases but sometimes not (maybe the overhead is just 1.5x, but if you're doing thousands of messages per second (not the usual API<>browser communication for web users)) and then it matters. Again it's trade-offs and highly contextual.
maccard 4y ago
> Wanna pass around data you don't know the schema of? JSON again. This is a false flag. If you don't know the schema on the receiving (or sending, for that matter) side, then you can't do anything with the data, other than pass it on. If you _do_ know what it looks like, then it has an implicit schema whether you call it a schema or not.
francislavoie 4y ago
At the time, we needed interop with C. So that's why we chose protobufs. But it was a nightmare to work with in other languages. Including C++ for cross platform desktop apps where cross compiling became a problem too. JSON in C is unfortunately way harder than in other modern languages (e.g. Go which makes it a breeze with struct tags and a great stdlib).
depr 4y ago
Surely the technical requirements of my specific use case are applicable to any use case.

ninepoints 4y ago

Honestly, gzipped json is likely much smaller than uncompressed protobuf. If you were going to use a binary protocol, why choose one that has no partial parsing/toc these days. There are much better alternatives IMO (flatbuffers being one of them)

oll3 4y ago
> Honestly, gzipped json is likely much smaller than uncompressed protobuf. Likely not. See here for a comparison: https://nilsmagnus.github.io/post/proto-json-sizes/ https://nilsmagnus.github.io/post/proto-json-sizes/ Btw, binary formats can also be compressed though it typically won't yield the same compression ratio as similar json would since there will be less repeation in the binary format.
- ninepoints 4y ago
  Or, we could have done a comparison with large strings and see the opposite result. Silly benchmark is silly (or should I say, specific)

speedgoose 4y ago

JSON messages in a compressed websocket stream are surprisingly tiny. Bigger than compressed protobuf packets but not by much, and much smaller than uncompressed protobuf packets.

capableweb 4y ago
Yeah, which is probably fine in most cases but sometimes not (maybe the overhead is just 1.5x, but if you're doing thousands of messages per second (not the usual API<>browser communication for web users)) and then it matters. Again it's trade-offs and highly contextual.

maccard 4y ago

> Wanna pass around data you don't know the schema of? JSON again. This is a false flag. If you don't know the schema on the receiving (or sending, for that matter) side, then you can't do anything with the data, other than pass it on. If you _do_ know what it looks like, then it has an implicit schema whether you call it a schema or not.

francislavoie 4y ago

At the time, we needed interop with C. So that's why we chose protobufs. But it was a nightmare to work with in other languages. Including C++ for cross platform desktop apps where cross compiling became a problem too. JSON in C is unfortunately way harder than in other modern languages (e.g. Go which makes it a breeze with struct tags and a great stdlib).

depr 4y ago

Surely the technical requirements of my specific use case are applicable to any use case.