Thrift for Bidirectional Messaging

Question

I am curious if Thrift is a good fit for my use case? I am making yet another messaging system, where there is a client and server, but both client and server and initiate a request message to the other, and not all messages may be request, just notifications.

Go back 10 years ago I did this with a hand-rolled binary based codec. Go back 5 years and I did it again using Google Protocol buffers. But I'm hearing more about Thrift now.

Can Thrift be used simply as a codec, or is it really built around the request/reply pattern? I need to remain transport agnostic as I will be using a custom messaging bus, websockets and likely zeromq.

I'm also considering messagepack and protocol buffers as I know they do lend themselves well to non request/reply messaging patterns.

Thanks.

Answer 1

I've only worked closely with the C++ version of Thrift, so this answer is based on that - it might be true for other languages also, and it might not.

From my experience though, Thrift is rather modular - giving you a complete stack that can handle RPC, socket communication, serialization of data, and basically anything inbetween.

You start out by specifying your data structures and services in a Thrift IDL-file, in a way that resembles how you would specify member variables (for data structures) and member functions (for services) in a class (in C++/Java/etc.). You compile these with the Thrift compiler to generate language-specific source files, which you can then implement in your application.

If you use the complete stack, it's then just a matter of creating the necessary objects (servers, protocols, transports, etc.) and open a connection between a client and a server (where the server implements the IDL-specified functions). The client can then call the functions on the server, just as if the server was a local object, using the custom-defined data structures (or just some of the standard Thrift datatypes) as parameters and return values.

The functions are blocking by default, that is, they require an answer from the server before they return. You can however also specify functions as oneway (as long as they return void), in which case you'll just send off the function call, and proceed immediately.

However, all this is only the case if you use the complete Thrift stack. You create your clients and servers by instantiating the various objects (protocols, transports, handlers, servers, etc.), and, although I've never tried it myself, I can't see why you shouldn't be able to create a derived implementation of for instance the transport, and then use that instead of Thrifts own transports.

If you just want to use Thrift to define data-structures in a cross-platform way, you can also do that, then use Thrift for serializing these (ignoring the rest of the stack and the RPC-stuff), and then send these as binary data over your own transport.