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.