Five Practices for Robust Ruby on Rails Applications

This article was originally published on Brewhouse's blog by Philippe Creux, and with his permission, we are sharing it here for Codeship readers.

Whenever I come across a Rails application with inconsistent data or bugs that are hard to nail down, I tell myself: “They (the developers) were just a couple of keystrokes away from preventing those issues from happening.”

At Brewhouse, we follow five simple practices to make our Rails applications robust. It all comes down to failing early, loudly, and often. We ensure that data is valid and applications behave properly by catching issues early on.

unexpected method 'upcase' for nil… Whenever you expect a hash to contain a key, prefer fetch() over []. fetch(). This will raise an error when the key is missing so you won’t pass nil values around and see unrelated errors happening down the line.

Always add an else raise ... clause to your case statements. You want to know when you’ve received an unexpected value rather than ignoring it and moving on.

Data is often seen as the most valuable asset in a company. Failing silently to persist data can have a huge impact. Whenever you’re not expecting an operation to fail, use the “bang” version of create!, update! and destroy! that raises exceptions on failure. This extra key stroke will save you from dealing with inconsistent data.

Used in test code, this ensures that the setup doesn’t fail silently. There is nothing worse than a test that passes because the setup was incorrect.

Also, always wrap multiple calls into an SQL transaction to prevent your data from getting to an in-between state.

Pairing Active Record validations with the use of "bang methods" is a great way to ensure you persist valid data. For example:

class Post < ActiveRecord::Model
  validates :author, :blog, presence: true
  validates :published_by, presence: true, if: :published?
  validates :comment_count, numericality: { greater_or_equal_to: 0 }
  # ...
end

Your database is your best friend when it comes to ensuring data is present, not duplicated, and that orphans are not left in the database.

null: false

Given the fact that the large majority of columns are required in a database, you should define columns with null: false by default.

index ... unique: true

Did you know that Rails' has_one does not prevent duplicate associations from being created?

class Account
  has_one :account_settings
end
account = Account.create!
account.create_account_settings!
account.create_account_settings!
account.create_account_settings!
account.account_settings
 # => one of the three account settings you've created... -_-

The best way to prevent this from making data inconsistent is to add a unique index.

add_index :account_settings, :account_id, unique: true

The database will throw an error if you attempt to persist a duplicate record.

foreign_key

You don’t want orphan records in your database, do you? Foreign keys help such things from happening. I’d recommend using the Ruby gem schema_auto_foreign_keys to automatically add foreign keys on your behalf.

A few extra keystrokes here and there can save you from hours of debugging or recovering from inconsistent data. Use !, raise, validate, and database constraints. Your coworkers and your future self will thank you.

As always, feedback is greatly appreciated. I’d be happy to hear of any other practices I didn’t cover here.