4 ms·

For me the most important point in this article is that Thrift includes an RPC implementation while Protocol Buffers does not. This was very helpful while writ

For me the most important point in this article is that Thrift includes an RPC implementation while Protocol Buffers does not. 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.

bretthoerner 15y ago
I'm (honestly) curious why a custom serialization format and RPC was a better fit than HTTP for this problem. What was the payload like that made this a better fit?
- atamyrat 15y ago
  I don't think network overhead is the problem here, it is about ease of development. Thrift generates working server code and you just have to implement RPC functions. On PB, you need a stack to handle connections, parse messages, dispatch, etc.
  - lobster_johnson 15y ago
    Note that Thrift supports HTTP as a transport.
- ankrgyl 15y ago
  Thrift's RPC is (optionally) built on top of HTTP, but provides support for custom typesafe (kind-of) data structures and the conveniences of RPC. If you're sending data that's more complex than a single homogenous type, then delivering a structured message over RPC is a necessary abstraction.
ankrgyl 15y ago
Unfortunately, Thrift RPC is a pain in the butt for Python, especially if you want to code with Tornado (http://www.tornadoweb.org/ http://www.tornadoweb.org/). The Thrift-generated code necessitates either using Twisted (http://twistedmatrix.com/trac/ http://twistedmatrix.com/trac/) or writing in a blocking style. For Tornado users, the existing generated code is unusable, and the compiler doesn't facilitate generating client-side function stubs that support callbacks. Therefore, it is impossible to write a properly-working RPC mechanism with the tools that the Thrift compiler provides. The only way to get around this is to modify the compiler itself. On the other hand, generated code from Protobuf allows you to slide in an asynchronous callback function (although yes, you have to write like 50 lines of code to build an RPC implementation). I can't speak for other languages, but given Thrift's inflexibility with Python, I suspect the situation is at least as bad for less common languages.

bretthoerner 15y ago

I'm (honestly) curious why a custom serialization format and RPC was a better fit than HTTP for this problem. What was the payload like that made this a better fit?

atamyrat 15y ago
I don't think network overhead is the problem here, it is about ease of development. Thrift generates working server code and you just have to implement RPC functions. On PB, you need a stack to handle connections, parse messages, dispatch, etc.
- lobster_johnson 15y ago
  Note that Thrift supports HTTP as a transport.
ankrgyl 15y ago
Thrift's RPC is (optionally) built on top of HTTP, but provides support for custom typesafe (kind-of) data structures and the conveniences of RPC. If you're sending data that's more complex than a single homogenous type, then delivering a structured message over RPC is a necessary abstraction.

ankrgyl 15y ago

Unfortunately, Thrift RPC is a pain in the butt for Python, especially if you want to code with Tornado (http://www.tornadoweb.org/ http://www.tornadoweb.org/). The Thrift-generated code necessitates either using Twisted (http://twistedmatrix.com/trac/ http://twistedmatrix.com/trac/) or writing in a blocking style. For Tornado users, the existing generated code is unusable, and the compiler doesn't facilitate generating client-side function stubs that support callbacks. Therefore, it is impossible to write a properly-working RPC mechanism with the tools that the Thrift compiler provides. The only way to get around this is to modify the compiler itself. On the other hand, generated code from Protobuf allows you to slide in an asynchronous callback function (although yes, you have to write like 50 lines of code to build an RPC implementation). I can't speak for other languages, but given Thrift's inflexibility with Python, I suspect the situation is at least as bad for less common languages.