Thrift vs. Protocol Buffers

For me the most important point in this article is that Thrift includes an RPC implementation while Protocol Buffers does not.<p>This was very helpful while writing an iPhone application that records audio and sends it to a server for voice recognition processing. Thrift allowed me to setup the iPhone client and the Windows/C# server in only a few lines of code. Protocol Buffers required that I establish a socket connection, send the audio data across, and then reassemble the data on the server side. Not the worlds most difficult problem, but being new to Objective-C at the time it was a bit tricky. I wish I had known about Thrift when I was building my initial implementation based on Protocol Buffers.

When I first read about protocol buffers, I was surprised at the similarity to ASN.1/BER: <a href="http://en.wikipedia.org/wiki/Basic_Encoding_Rules" rel="nofollow">http://en.wikipedia.org/wiki/Basic_Encoding_Rules</a><p>Basically, they're both nested type/length/value data formats with primitives for numerics, strings, etc with an human readable description language and toolsets to auto-generate language types + (de)serialisers etc.<p>Given that the ASN.1 toolset exists (even if a little dusty, SNMP and X.509 keep it alive) I don't see why google bothered to re-implement.<p>The FAQ: <a href="http://code.google.com/apis/protocolbuffers/docs/faq.html" rel="nofollow">http://code.google.com/apis/protocolbuffers/docs/faq.html</a> mentions ASN.1 but it's main argument (being tied to a particular form of RPC) doesn't apply to ASN.1.

Although not mentioned in the article Go now has support for Protocol Buffers:<p><a href="http://code.google.com/p/goprotobuf/" rel="nofollow">http://code.google.com/p/goprotobuf/</a>

The serialization/deserialization times are <i>dramatically</i> different for Python. Thrift has an accelerated binary serializer written in C with Python bindings, while Protobuf's is pure Python. While there exist third party C++ wrappers for Protobuf in Python as well, they are buggy (segfaults).

I personally really like mspack and msgpack-rpc. There are a tone of well supported implementations for various languages and there are some speed and other advantages over thrift and Protocol Buffers. The core implementation is written in C++.<p><a href="http://msgpack.org" rel="nofollow">http://msgpack.org</a>

I am very cautious of Thrift's custom network stack.<p>We have a java backend service that gets thousands of requests per second per node and where latency is of upmost importance. We tested thrift for communication between the backend service and the front end web code, however we saw an increase in failed requests and latency compared to a server written using netty.<p>For us, using netty and Protocol Buffers works much better, but maybe we were using Thrift wrongly.

Some of the protobuf implementations are a bit more official than others. We are using the Go protobuf plugin at Tinkercad and it's maintained by Google for internal use. Given the importance of protobufs in communicating across Google is pretty safe to assume that the implementation is solid (disclaimer: I used to work at Google and know the folks maintaining the Go plugin).<p>That said, we are starting to miss a Javascript protobuf implementation. There is a lot of binary data to serialize across the client/server boundary and not all of it requires a custom format. It would be nice to just drop in server side protobufs and have them work seamlessly on the client.<p>I do understand the criticism about the missing RPC library but I've always found that you need to write your own anyway.

I like how this thing looks <a href="http://msgpack.org/" rel="nofollow">http://msgpack.org/</a> more than each of the aforementioned. Perhaps I'm missing something, but Thrift and protobufs both seem very lacking in comparison

Protocol Buffers are versatile, allowing nesting and includes but performance we got on Java server and PHP/iOS client was pretty poor and PHP libraries do not support whole specification.<p>So we switched to Thrift and whole FB stack with HipHop and Scribe and we're thrilled. Documentation is a problem just at the beginning when setting up the stack. Everything else later is self explanatory.

&#62; But thrift and protobuf are by far the most popular<p>[citation needed] <i>(seriously, I'm interested)</i><p>XML seems far more popular (in the sense of market-share/adoption, not in the sense of being liked).