Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Protobuf instead of JSON to communicate with a front end

blog.wearewizards.io

Post reply on HN
Print view View original

11–20 of 99 posts

Re: Using Protobuf instead of JSON to communicate with a front end

#15

Post by zubspace »

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

Re: Using Protobuf instead of JSON to communicate with a front end

#16

Post by VikingCoder »

swalsh wrote: post #13

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, but you can use tags, as I see you have done in your example. This should not be an option. Everything should be extensible by default, because people are very bad at predicting whether they will need to extend something later.

The bigger problem with ASN.1, though, is that it is way over-complicated. It has way too many primitive types. It has options that are not needed. The encoding, even though it is binary, is much larger than protocol buffers'. The definition syntax looks nothing like modern programming languages. And worse of all, it's very hard to find good ASN.1 documentation on the web.

It is also hard to draw a fair comparison without identifying a particular implementation of ASN.1 to compare against. Most implementations I've seen are rudimentary at best. They might generate some basic code, but they don't offer things like descriptors and reflection.

So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller, faster, more robust, and easier-to-understand ASN.1.

Re: Using Protobuf instead of JSON to communicate with a front end

#17

Post by soldergenie »

rektide wrote: post #8
soldergenie wrote: post #6

Earlier quoted context omitted.

Grpc doesn't work over the browser. This is stated explicitly in the FAQ. See https://groups.google.com/forum/#!topic/grpc-io/5Ic8MKgltwY

It's rather painful that they don't seem to have any design docs up for their HTTP transport, leaving it to things like FAQ entries to explain these details. This was my first thought too- grpc does this.

The protocol is documented - https://github.com/grpc/grpc-common/blob/master/PROTOCOL-HTT...

However, you still need the FAQ to figure out that browser transport isn't supported

Re: Using Protobuf instead of JSON to communicate with a front end

#19

Post by skybrian »

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.

Re: Using Protobuf instead of JSON to communicate with a front end

#20

Post by teh »

skybrian wrote: post #19

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.

Can I ask which library you are using? I found a few [1] but none seem super robust.

Also, how do you deal with the bytes type?

[1] https://code.google.com/p/protobuf-json/ https://github.com/benhodgson/protobuf-to-dict

Post reply on HN