This is a very actual topic, for those want to avoid (or just try to avoid) the mistakes or even the bad project decisions from a recent past.
Introduction
The term 'Hexagonal Rails', came up recently, and you can thought that is related with a new technique in the software development field. But it's not, this is about Architecture, and how to achieve a software with loose coupling and high cohesion.
In order to guide my discurse in a more objective way, I'll use now the Andrzej's post called The Rails Culture and The Rails Way.
Andrzej's Post
In this post, Andrzej traces a brief history of Ruby on Rails and how it changed the business world. I believe we can say, that Rails Way brought the RAD (Rapid Application Development) concept to the web applications world.
Rails Way
His post became more interesting when he starts to explain the Rails Way. The quotes bellow was extracted from there:
"When The Rails Way concept was appearing it was a way of distinguishing it from "the architecture astronauts Java way" or the "PHP spaghetti way". We needed to be unique and have something to unite us. "
"Most of our community DNA was very good, but there was also something negative. A big part of the Rails community was united with the anti-Java slogans. Everything Java-like was rejected. XML? No, thank you, we've got yaml. Patterns? No, thanks. "
"We've got ActiveRecord. We take the object from the database row and use it in all the three layers. Fat models or fat controllers? Whatever, let's just not create new layers."
For me, these quotes express well the Railer spirit. I confess that I like this rebel attitude, but we (as software developers) must to be careful with generalizations. It's important to notice, in that period Java developers were known for his BDUF approach. And I believe this helped to create that 'rebel spirit' in the Railers. But completely ignore movements such as Domain Driven Design was a mistake, in my opnion.
Characteristcs of Rails Way style
After that, Andrzej tries to summarize the characteristcs of the Rails Way style. The quote bellow shows these characteristcs:
- ActiveRecord objects everywhere, including the views
- External gems used for most of the features
- Non-trivial logic implemented with the combination of filters, callbacks, validations, state-machine - often in a non-easy-to-follow-way.
- Magic - Convention over Configuration, DRY, metaprogramming
- Only 3 layers - Models, Views, Controllers
Consequences of Rails Way style
These characteristcs leads to projects with a "harder maintenance code base". To illustrate that, I'll use a quote extracted from a famous blog post called Your Code is My Hell. In this post Avdi Grimm says:
But here’s the dirty little secret of Rails development: the messiest, nastiest big-ball-of-mud code I have seen in my entire career has been in Ruby on Rails projects. I’ve seen Rails projects that accumulated enough technical debt and waste in two years to make 10 year-old C/C++ programs look clean and elegant by comparison. And it wasn’t just one project. I’ve seen it over and over. -- [Avdi Grimm]
Like Avdi, I had my tribulations too. And I can say that "I ate my own dog food" when a had to migrate a Rails Way Application from Rails 2 to Rails 3. Man.. it was a really painful task.
At this point one thing it's obvious, the problem was not the tool (programming language) but the technique (architecture/engineering).
Considerations of Rails Way style
Don't get me wrong friend. I know that Rails Way is not evil all the time. But in this post I'm not considering small applications (very small in fact) just the big or more complex ones.
For different results you need a different approach
When a faced myself with the opportunity to start a new project, I realized that was the time to try something different. And that way, I started my Hexagonal Rails attempt.
In the next posts I'll discourse about this experience, showing my references (very good ones, in my opinion), and talk about how they influenced me, and showing code when possible of course ; )
Originally published at www.sagadoprogramador.com.br on February 23, 2015.