21–30 of 99 posts
"While I see the need for Protobuf and Thrift for services communication, I don't really see the point of using it instead of JSON for the frontend." Ah Ok whew, so the title was wrong or designed for click bait.
I always wondered why google decided to build Protocol Buffers. ASN.1 seemed like it worked well, and it covered all the corners.
Here was Kenton Varda's response: https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4 My understanding of ASN.1 is that it has no affordance for forwards- and backwards-compatibility, which is critical in distributed systems where the components are constantly changing. ... OK, I looked into this again (something I do once every few years when someone points it out). ASN.1 _by default_ has no extensibility,…
I like to use Protobuf in my server code, but then support JSON _or_ Protobuf as the encoding. So browsers can continue to use JSON, but the server gets strongly-typed Protobuf structures.
if you are using a statically typed language, binary formats like Protobuf are a big win, but if you are going to have the dynamic language overheard that comes with JS, there isn't much gain to be had from binary formats.I like to use Protobuf in my server code, but then support JSON _or_ Protobuf as the encoding. So browsers can continue to use JSON, but the server gets strongly-typed Protobuf structures.
It's possible to encode a protobuf as JSON and we do it all the time at Google. In browsers, native JSON parsing is very fast and the data is compressed, so going to a binary format doesn't seem worthwhile. The .proto file is used basically as an IDL from which we generate code.
The most common method is to use an array indexed by the field number. I've seen protobufs with hundreds of fields so that's hundreds of nulls as the string "null".
The alternative is to have JSON objects with attributes named after the protobufs field name. This isn't without warts either and seems to be less prevelant in my experience.
Another problem is JavaScript doesn't support all the data types you can get in protobufs, most notably int64s.
Protobufs are relatively space efficient (eg variable width int types). JSON encoded protobufs much less so.
Perhaps the rise of browser support for raw binary data will make this less awful.
Many consider it a virtue to use the same code on the client and server. It explains things like this and GWT. Personally opi think this is horribly misguided and a fools errand. You want to decouple your client and server as much as possible (IMHO).
Disclaimer: I work for Google
One thing, where protobuf (at least protobuf-net) really shines, is serialization of data into a binary format which is incredibly fast. In .NET, all inbuilt alternatives are slower by a large margin. https://code.google.com/p/protobuf-net/wiki/Performance
I like to use Protobuf in my server code, but then support JSON _or_ Protobuf as the encoding. So browsers can continue to use JSON, but the server gets strongly-typed Protobuf structures.
proto3 supports both binary protobuf encoding and JSON natively, so you can switch between them as desired. https://developers.google.com/protocol-buffers/docs/proto3
proto3 is currently in alpha, but we are working to bring it closer to release (I work on the protobuf team at Google).
I like to use Protobuf in my server code, but then support JSON _or_ Protobuf as the encoding. So browsers can continue to use JSON, but the server gets strongly-typed Protobuf structures.
What you describe is exactly how proto3, the latest version of protobuf, will work! proto3 supports both binary protobuf encoding and JSON natively, so you can switch between them as desired. https://developers.google.com/protocol-buffers/docs/proto3 proto3 is currently in alpha, but we are working to bring it closer to release (I work on the protobuf team at Google).