Hacker News new | comments | show | ask | jobs | submit login

> Google's Protobuf won't survive either, because simple text-based protocols always win

I expect Protobuf, Thrift (fbthrift) and Avro to be around for quite some time. Once you know what they're good for, everyone likes binary formats that can be easily shared across multiple languages via code gen. You can turn every binary format into text-based for debugging purposes using standard commands. Heck, even Apple has binary plists. It's natural that a format eventually gains (or is based on) binary alongside text -- for those times when binary is simply faster. Now, if it's just transmission speed, you can convert text to binary using gzip.

Frankly, the key to success for protobuf or thrift as independent projects is how much adoption you see outside of the companies.

Oh and I'd also point to the "death of rest" in http://techblog.netflix.com/2012/07/embracing-differences-in... -- just as websites provide front-ends to a myriad of backend services, so too can API servers provide a consistent, simple front-end for devices. Not sure what to call it, since as a pattern, it doesn't require a specific protocol, and it could be considered somewhat HATEOAS, except state is easily maintained client-side these days....




I worked with Protobuf and while doing so I had 3 problems - the generated classes were freaking monsters, crashing my IDE, those classes must be used with the precise library version of the generator that was used and in spite of tools available for easy debugging, I couldn't find out one that didn't suck, plus the output is not the only problem, input is a problem too. In practice it's actually a bad idea to parse the whole freaking blob and/or carry around monster classes that specify how, when in essence you end up carrying only about some paths.

And while I thought that the availability of that spec was an advantage over an undocumented JSON-based protocol, in truth an undocumented spec is just as bad as an undocumented JSON-based protocol and at the very least with a JSON-based protocol you have an easier time doing reverse engineering, since playing around with the request format doesn't involve writing code to do it.

Besides, there's nothing about binary protocols that makes them better for code-generation tools. That people don't do this for JSON is only because with JSON you don't need to and it's often preferable to not do it.

There is something to be said against JSON - for objects in arrays, the keys are redundant for example, which adds up when parsing a long document. But there's nothing inherent in a text-based protocol that disallows you to first define the shape of the data before describing the data in more concise terms, while keeping it fairly readable at the same time. And I'm unconvinced that something like Protobuf brings benefits unless you're working at a Google-like scale and I did work on an ads platform that integrated with various bidding exchanges and that was operating on an insane scale and the bidding exchanges I loved were the ones with the protocol based on JSON, while at the same time I had countless problems with those based on Protobuf.

> Heck, even Apple has binary plists.

And personally I hate it, because instead of opening that file with a plain text editor, or as a text file handle, I now have to use special-purpose tools or libraries. Binary plists sit somewhere between Unix-like text config files and the Windows registry and the closer you get to the Windows registry, the more I hate it.


>>everyone likes binary formats that can be easily shared across multiple languages via code gen

Everyone? P buffers and code gen create a static protocol that's more hard to modify OR extend than text; more moving parts: the spec file, the generated code, the code generator, and the lib for your language. Code gen adds complexity to development, build, and deployment. Binary protocols are more difficult to test than typing some json into Postman for example.

Http is the canonical example of the successful text protocol.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: