Apache Thrift Library | Hacker News Reader

Apache Thrift Library

thrift.apache.org

24 pointsUnboxed12 comments

Facebook`s internal RPC Framework

We use both thrift and protobuf, and my experience with both has been very positive. I feel that protobuf is more mature and has better performance for the most part, but thrift does provide built in RPC support, which protobuf doesn't.

I think if I wanted to implement RPC I'd use thrift again in a second, and if I was sure I wanted only message passing/serialization, I'd go with protobuf again.

The other main factor is language support - while they are both very good at this, they have slightly different support, and if native PHP support is important to you, Thrift is a better choice, as well as for a few other languages as well.

If you are looking at Thrift, you should take a look at ZeroMQ too: http://www.zeromq.org ZeroMQ provides only ways to send/receive messages over several transport mechanisms (sockets on steroids) and address them to specific clients. It does not define what is the content of the messages, so you can send JSON/BSON/Protocol Buffer or whatever you come up with.

I work with it every day and it is a pleasure every single day.

Evernote uses Thrift. It makes sense to use it or something similar over a plain-text format if you control the server and the client and send a lot of data back and forth. Evernote has gone farther than that, though, providing a public API for it:

http://www.evernote.com/about/developer/api/ref/

This looks like it could solve a lot of problems. I will look into this in greater detail later; I would like to see whether this can be used as a web service.

If I can write my web service in C++ and call it in Javascript, that would be amazing.

Not to take away from thrift in any way but could you not do this already using any portable serialisation method? Json has c++ and JavaScript (de)serialisation implementations as does XML. Combined with a Rest-ful web service api surely it doesn't matter what the transport mechanism is?

I guess their focus was on speed. XML is pretty slow and verbose, and whilst JSON is better, it's not the best solution. MongoDB's BSON is quite cool though.

Web Services and the associated HTTP headers are relatively slow, but browsers can make them, so are kind of necessary.

JSON does not work well for binary data. BJSON tries to fix this, but in languages like C++ you will still have to deal with clumsy parser syntax when you deserialize your stuff. It's much more convenient to have native classes representing protocol objects in your language (protocol compiler generates them for you).

Well, Thrift is an RPC mechanism; while it can use an HTTP transport, I'd say it makes more sense to use raw TCP streams to call it.

If you want to develop a web service in C++, you could check out the available web frameworks, like OKWS[1], CppCMS[2] or TreeFrog[3].

[1]: http://okws.org/doku.php?id=okws [2]: http://cppcms.sourceforge.net/wikipp/en/page/main [3]: http://www.treefrogframework.org/

Is this another protocol buffer implementation, or am I misunderstanding that?

Actually, it's from the same guy who implemented protocol buffers when he was at google. He re-implemented a better protocol buffers for facebook and chose to call it Thrift.

I wouldn't say that Thrift is clearly better then Protobuf. It's more like they solve slightly different problems and make slightly different tradeoffs.

Has anyone tried this with a Python backend and a Ruby user interface?

Reply on news.ycombinator.com