I didn't use Rails for quite a while. Recently I decided to take part in one project to refresh my skills and knowledge of Rails.
I was trying to follow the Rails way as long as I can. Once I've got into troubles, I switched to my "fallback strategy" - I started using extra building blocks like Services, Form Objects etc.
Although, even after that I wasn't satisfied with the result. I saw that if the app will keep growing, I will have problems.
I had the same exact feelings like wo years ago, when I was using Rails more actively. Nothing has changed, I still had more questions than answers.
Quick research demonstrated that the state of Rails community is still more or less the same:
The major difference between now and then is that Ruby underground (Hanami and DRY) has become mature. If you're tired of Rails, but still in love with Ruby, you have a place to go.
Though it is important to realize that 90% of Ruby jobs are Rails-related, so it might be hard to find a practical usage of Hanami.
I personally gave Hanami a try, and I was a bit disappointed. Yeah, Hanami is based on the Clean Architecture principle, it has a strong flavor of Java. It is not necessarily a bad thing, of course. Although, it forces you to care about all the building blocks up-front. It means that you have to write a lot of boilerplate code, therefore more work when you're starting a new project.
I can't say for the whole community, but my personal We're spoiled by Rails approach when you get a lot of things done by a little of code. I love when framework allows a certain amount of laziness. Unfortunately, it is not about Hanami.
It is hard to predict the future of Hanami, but I doubt that it will become a mainstream.
Can we get something in between?
Here's what happens to a lot of Rails developers:
I am not saying it is the only possible trajectory, but it is what happened to me.
This final position is very uncomfortable. It is because you can't rely on simple rules anymore. Now you have to turn on your thinking process:
..and millions of other interesting questions.
Luckily enough, I recently attended a workshop of Hexlet CTO, Kirill Mokevnin. He described their way of organizing code in Rails applications.
When I listened to it, it felt like he is telling me the contents of a book I always wanted to write. Basically Kirill described a set of conventions and techniques to prevent negative effects of Rails.
So, I have some good news for you:
And the bad news:
So, that's me again full of aspiration to finish the book, I started more than two years ago :) In fact, it will be a different book, but it is going to serve the same purpose - to help Rails developers produce maintainable Rails applications.
Leave your email in the form below if you want to receive updates. Cheers!