In Praise of Rails REST, MVC and Conventions

Guiding Principles

I’ve been thinking about the “good old days” of Rails development. It seems there was a time where Rails conventions were more closely followed. Perhaps because the community was smaller. Perhaps because developers felt that the Rails conventions supported the smaller apps of the time.

Recalling these simpler days, I’d like to review the simplicity and power of the REST/CRUD combo by offering reminders of some of the well-known benefits of sticking with this convention.

Stick with REST/CRUD

It’s not sexy. (You know what is sexy? Delivering quality code, quickly.)

Compared to alternatives, REST/CRUD is

* Easier to understand
* Easier to maintain
* Easier to test
* Easier to API

Easier to Understand

Remember that the future you or future developers will need to understand the application’s flow and logic. The greater number of custom methods or actions the application has, the harder the code is to understand and follow. Everyone knows what the create action does. Everyone knows where to go to find the code that creates an object. But when code is in a custom add_comment action, it becomes non-obvious where to find the code that creates said comment.

DHH:
Common problem I see in Rails code: Too few controllers. More controllers doing less work obviates need for many other fancy patterns. You can have many controllers all directing a single model but in different contexts. Less if/else, simpler views, simpler actions. This becomes easier to do if you’re militant about only exposing REST CRUD from each controller. Any deviation => new controller. https://twitter.com/dhh/status/453181241127620608

As a side note, a reminder to keep controllers thin.

When code is in controllers the code tends to get very complex, very quickly. Most domain logic should be in models or modules. This reduces the number of “paths” through the application, reduces the number of interface points between the client and server, and reduces the number of places where code must be maintained and troubleshooting occur.

Easier to Maintain

When building Ruby on Rails, MVC, database-backed, web-apps, use the power of Ruby objects, ActiveRecord, and friends. When you think that ActiveRecord will not be up to the task for your special case; give it a try anyway. You will be surprised at AR’s performance and at the speed at which you can develop.

Easier to Test

The more that code follows convention and uses Rails as-is, out-of-the-box; the fewer tests need written. Remember: “don’t test the framework”. You could end up with entire controllers and even small models which require no or very minimal tests.

Easier to Expose an API

Rails gives applications a REST API basically for free.

In general: Be Thoughtful in Design

Programmers who know nothing about object-orientated design can be very successful in Ruby. However, successful but _undesigned_ applications carry the seeds of their own destruction; they are easy to write but gradually become impossible to change.

– Sandi Metz , “Practical Object-Oriented Design in Ruby”

Be vigilant, thoughtful, purposeful in design. Stick to convention and may that day when your application becomes impossible to change never come.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s