So today I started my day with reading recent posts on rails-core group and one post looked interesting to me: Add support for multiple, concurrent, connection pools. ActiveRecord and threads and multiple databases. What could possibly go wrong?

Ruby developers use Active Record

So I commented on our Ruby User Group IRC channel that it is exactly the reason why we choose not to use AR in our newest product chillout.io. If you are interested in this topic I strongly recommend reading ActiveRecord Concurrency Currently: Good News and Bad. The next obvious question was, so what do we use?

Except when they don’t

We use Sequel. I wanted to use Sequel since the moment I read How I Test Sequel article written by Jeremy Evans, the creator of Sequel. But I never had the reason (or the guts) to leave my comfort zone of using ActiveRecord.

Ruby developers use Rails

The next question was: How does it work with Rails ? What problems did you encounter? Well, I don’t know.

Except when they don’t

It struck me into my head that it was automatically assumed that our app is Rails app when it has no reason to be it. It is a built from multiple components (currently 3 but this number will grow in future) which communicate together using Sequel, ZMQ and Queues. Because monitoring your app might be about many things but none of them makes much sense when being put into Rails. We wanted to avoid building monolithic architecture at all cost. Even if that means getting our hands dirty and dealing with lot of new things at the same time. But it was a necessary step to guarantee isolation and scaling of the components, which all has completely different needs.

We ❤ Ruby, Rails and ActiveRecord

We love all those tools, built many products using them and made our customers happy.

But that does not mean we should use them in every project. We chose a different toolset because we believe it is now finally time to start caring more about threading and concurrency in a whole Ruby community and the best way to do it, is to give it a try in real-life projects. And use tools that were built with threading in mind.

Try it out

So, wanna give a try to Ruby but Not-Rails-Not-Even-ActiveRecord application? Sign up!

comments powered by Disqus