4 ms·

Apache Thrift Library

• alexchamberlain 15y ago
  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.
  • rojabuck 15y ago
    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?
    • alexchamberlain 15y ago
      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.
    • azov 15y ago
      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).
  • icebraining 15y ago
    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 http://okws.org/doku.php?id=okws [2]: http://cppcms.sourceforge.net/wikipp/en/page/main http://cppcms.sourceforge.net/wikipp/en/page/main [3]: http://www.treefrogframework.org/ http://www.treefrogframework.org/
• Loic 15y ago
  If you are looking at Thrift, you should take a look at ZeroMQ too: http://www.zeromq.org 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.
• wlievens 15y ago
  Is this another protocol buffer implementation, or am I misunderstanding that?
  • plq 15y ago
    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.
    • azov 15y ago
      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.
• benatkin 15y ago
  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/ http://www.evernote.com/about/developer/api/ref/
• edan 15y ago
  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.
• tritogeneia 15y ago
  Has anyone tried this with a Python backend and a Ruby user interface?