Pros and Cons of the Rails Application Architecture
Discover the strengths and challenges of the Rails application architecture. Learn why Rails simplifies starting projects with fewer upfront decisions and how to intentionally manage business logic. Understand Rails' focus on database-backed apps and the importance of user-centered development for sustainable applications.
We'll cover the following...
Power of Rails application architecture
It’s important to understand just how powerful the Rails application architecture is. Working in any other system (at least one that did not just duplicate Rails) requires a team to make a lot of decisions about the internal architecture before they even start.
In most situations, teams will end up designing something that looks like Rails anyway.
What this means is that a team working on a Rails app doesn’t have to make a bunch of big up-front decisions in order to get started and they don’t have to worry about big drifts in the structure of the codebase.
Pros
We can also easily work within this architecture to create a sustainable application. We don’t need to abstract our code from Rails or create a framework-within-a-framework. We just need to be intentional in how we use Rails and fill in a few gaps for cases where Rails doesn’t provide guidance for what we should do.
Cons
There are two downsides to the Rails application architecture. The first is that it’s designed to build a particular type of application: a database-backed web application. If we aren’t doing that, Rails isn’t much help. The second downside is one Rails can’t really do much about. Rails provides no guidance about where business logic should go. The result is that every Rails developer we’ve ever met has a slightly different take on it, though those same developers also have had a bad experience with a variety of strategies.
It’s important to understand that while David Heinemeier Hansson (DHH), the creator of Rails, might put business logic in models, the Rails documentation doesn’t explicitly say this—developers used to put them in the controllers before the fat model, skinny controller aphorism became popular.
We strongly believe that software should be developed with a user focus, and that the behavior of the software must flow from the user. This means that working outside in is preferred. If we know the user experience we want to create, the code we write can then be laser-focused on making that experience happen.
Before we think about the user, we have to have a working environment first, and we have to have some semblance of a Rails app in which to work.