ActiveRecord Meets Thrift

I stumbled across the Thrift framework not so long ago and have been intrigued ever since because of it’s promises. And it’s easy to fall in love with the marketing and promises of any framework when it tickles and uses the words and phrases you like to hear, not so?

So finally, I have the opportunity to test drive it: in a design that will become a product that will be released into production in the not so far future. So I want to make sure it’s ticking along as I would expect it to, especially if I want to test, implement, debug, deploy, maintain, scale and extend. And so far, i’m tres impressed.

On the server, I have the default Thrift server, Ruby flavoured, running on Mac OS X with a CSharp client on a Windows XP box (same LAN) and all with no extra tinkering; just as is, courtesy of the generator. Luverly stuff! And then, the implemented handler on the server uses ActiveRecord to handle the database lifting. No Rails: just Thrift and ActiveRecord. And it rocks (so far).

I’ll more than likely be documenting this implementation in more detail over time since the combination opens up many more opportunities in the space i love to work play in. And that’s including the spike project source code.

References and gratitude to the following authors/posts which assisted in getting this going:


Morty py

Morty py is the same Morty that was built using Ruby on Rails as part of a bigger scheme related to the basics of financial learning, specifically the concept of amortisation. Morty py, as it’s creative name suggests, is a Python implementation. Moreover, it’s also hosted on Google’s AppEngine.

In all, the differences between the frameworks and development experience are both varied and the same. It doesn’t really matter which is “better”- that discussion is a moot point. But in summary, i love the RoR implementation for it’s expressiveness in code and coherence of the MVC pattern. But Google’s AppEngine rocks when it comes to functionality and the tool chain. Performance (for this app) is much of a muchness. Python is really nice, and so is Ruby. Granted, getting to grips with Python was much easier, but that’s only because my multi-lingual skills have improved greatly. And being a multi-linguist is so much more satisfying.

Afterall, imagine, in one day, coding the backend in Python, some related services in Ruby, maybe an optimized service in C, with a front end in C#, possibly ASP.NET or WinForms, a mobile front end in Java and then some obligatory JavaScript to boot. Not forgetting the frameworks that come with each of those languages that make them ultimately productive. For me, seventh heaven 😉