So last week we made TykRMQ open source, TykRMQ is a wrapper around the Pika library that helps integrate and work with RabbitMQ queues in Python. Don’t get me wrong, Pika is great (it’s made by the guys at RMQ, how can it not be!?), but it also introduces a lot of overhead when working with queues – especially if you want to use the pass-through style of setting up non-blocking queue interactions.
So, what makes TykRMQ so great? Well, we’ve used in our own projects. Loadzen, our load test platform is currently undergoing a rewrite and we used Tyk to power the backbone of the application, so it’s completely decoupled. It’s also integrated into my sonopy project, an experiment in creating a scalable multi-room sound system using Raspberry Pi’s and ODroid U2’s.
The software started life as a full-blown enterprise service bus we were tinkering with at Jively, but we’ve now parked the project and stripped it for salvage – TykRMQ is what remained.
The whole point of TykRMQ is to make it really simple to build the bits of your application that will be distributed in a patterned way, ensuring a repeatable, easy to implement and structured methodology for creating components that interconnect.
This is what a TykRMQ application looks like:
Basically, you would build your application as a series of independent, testable classes. Then hook these into a TykRMQ component and wire your output and input functions to the queues you define in the framework, resulting in an easy to manage communications layer, while keeping your code highly testable.
So, how does this voodoo unfold? Basically all TykRMQ does is implement the standard Pika pass-through code, separate it out into logical break points and add some convenience methods to it so you can glue them together.
The idea is simple: You define your configurations in terms of how you want to your queues to be registered with RabbitMQ, you create QueueAction classes for your input and output queues, QueueActions are the event-driven bits that _do_ things when a message is sent or received and then use a BaseComponent class to initialise and enable them all to speak to each other via named keys.
A component can have any number of inputs or outputs, and you can programatically generate queues and actions if you need something really flexible. In the next few weeks I hope to be putting up some more code samples to give a better impression of how to use TykRMQ, in the meantime, take a look at the Hello World sample in the bitbucket repository, and if you have any questions or want to help build out TykRMQ, give me a shout on twitter.