Facebook Thrift - less horrific than SOAP

A while back, Facebook publicly released their internal RPC thingy, Thrift. For some reason, perhaps because it altogether lacks the flashiness required for Web 2.0, it has barely gotten any notice at all. I only found out about it accidentally this week.

It seems, though, to be very good. Very, very good. At least very, very good compared to the competition, which, when it comes to it would not be hard.

You see, if you want to do cross-language RPC, you have few choices. There's CORBA, which is ancient and scary. There's ASN.1, which is not strictly for RPC, and which I have never heard of anyone using, ever. There's DCOM, which is particularly frightening, Windows-only, and basically dead. Then there are the two people are most likely to be familiar with, XML-RPC and SOAP. Both of these are XML-based, and thus take a lot of bandwidth, and are in many cases slow. XML-RPC verges on feature-free (it won't even do 64bit integers) while SOAP can do just about any data type, assuming that you can figure out how to make it do so and your SOAP libraries on different languages get along. This post on SOAP really isn't exaggerating at all.

XML-RPC and SOAP are often used for webservices, but for high-volume communication in a distributed system, they are less than useful. Unsurprisingly, then, most giant webapps with lots and lots of different server software don't use them for that. Amazon and LiveJournal and so on all seem to have their own internal stuff, but to my knowledge, Facebook is the first to make theirs public.

So, what's it like? Well, really, really good, actually. It comes with libraries for each supported language (the usual suspects like C++, Java, PHP, Perl, Python, Ruby, plus a few oddities like Erlang, Haskell and OCAML. .NET is conspicuous in its absence, and indeed the whole thing is pretty Windows-unfriendly, at least for the moment). You write a service definition in a special language, and run it through their compiler, tellling it which languages you'd like it to produce bindings for. You then write simple code to interface with the bindings, and you're done!

It's designed so that you can use multiple transports and data encoding protocol. In practice, the only data protocol supported over a decent range of languages is a simple binary one, for the moment, but if you wanted something else, it would be quite easy to implement. Most languages have socket and HTTP interfaces.

The license is extremely liberal; as far as I understand it, about all it requires you to do is to include a copy with any derivative code you produce. Refreshing; so many otherwise useful libraries these days require you to send your first-born to Richard Stallman if you so much as look at them.

As a little project, I'm writing a Common Lisp backend for Thrift. Currently, I've got the transport and most of the protocol done, and was able to use it to talk to a Python server. Actual code generation is still to come, but should not be overly difficult.