5 tips to start on the right foot with Ruby on Rails

In this post I'll share 5 tips covering good practices, tricks, advice, and so on — I'm sure they'll help you get started the right way in the world of Ruby on Rails.

1. Nested resources…

Ruby on Rails makes it very easy to configure routes with nested resources. While there's no hard limit on nesting levels, the recommendation is to never go deeper than 1.

This is easier to explain with an example. Say we have the following structure:

# bad
resources :comunity do
  resources :users do
    resources :articles do
      resources :comments
    end
  end
end

The problem shows up when you want to access an article: you shouldn't need to specify the comunity_id or user_id. And what if you want a route that lists all users? Or all articles?…

The recommendation is to split the resources like this:

# good
resources :comunity do
  resources :users
end
 
resources :users do
  resources :articles
end
 
resources :articles do
  resources :comments
end

That said, this doesn't always hold — it also depends on the business logic of the project you're working on. For example, say we have an 'employee' resource that belongs to and depends on a 'department', which in turn belongs to a 'company':

resources :company do
  resources :departments do
    resources :employees
  end
end
 
resources :employees

In this specific case the routes above are actually necessary, since an employee belongs to a department and a department must belong to a company. We even keep a standalone resource at the end to manage all employees.

2. To scaffold or not to scaffold

There are plenty of arguments against using rails g scaffold: it generates a lot of extra code you usually won't need, it doesn't set up model relationships the way you want, or some people simply consider it a 'sin'.

In my (short) experience with Ruby on Rails, I've never used scaffold in real projects — often a resource doesn't need an 'index' or 'show' view, or the action methods end up with different logic, and so on.

Another reason I don't usually scaffold is that I work with TDD and BDD, which means writing unit, functional and high-level tests before starting to code — scaffold does generate all these tests by default, but they almost never match the actual business logic.

However, if you're learning Ruby on Rails or have very little experience, I do recommend using scaffold — not for production projects, but to study all the features, methods and code it generates, using them as a guide so you can later adapt it all to whatever you need.

I also recommend scaffold as a way to examine the kinds of tests it creates for models, controllers and views — again, to use them as a reference.

3. TDD, make your tests first…

Unit tests for models, functional tests for controllers, tests for APIs, etc.

If you want your whole application free of bugs from the start, the recommendation is to work with TDD — write the tests first, add the functionality, run the tests, and finally refactor the code.

BDD is also highly recommended; it pursues the same goals as TDD from a different point of view: "test what you see". This is where high-level tests, or acceptance tests, come in.

Besides, one of the main things tech companies look for in Ruby developers these days is experience working with TDD or BDD, so starting out with TDD from day one is not a bad idea.

Finally, keep in mind that applying TDD and BDD in a project will increase development time, so plan accordingly.

4. Rubocop and the Ruby Style Guide…

If you're looking for a solid reference on programming style, the Ruby Style Guide is for you — a set of guidelines and good practices focused on Ruby and Rails, released to help developers.

Rubocop, created by the same author as the Ruby Style Guide, is a gem that analyzes all your code looking for possible offenses, giving you an exact list of them while suggesting how to fix each one.

Rubocop is a highly recommended gem — it will force you to write quality code that's well structured and, above all, follows good practices.

5. JBuilder vs Active Model Serializer vs to_json() vs RABL

There's a lot of controversy around the methods used to render data as JSON, especially inside an API. Among them we have the built-in to_json() function, JBuilder, RABL and Active Model Serializer (AMS).

I'll say just a bit about each one, trying to give examples of where each should be used, their characteristics, and so on.

Which one is fastest?… AMS, because it doesn't render views from the controller (as JBuilder does).

When to use JBuilder?… If the structure of the JSON you need differs a lot from your model's attributes, I recommend JBuilder — inside its templates you can use Ruby code, which gives you great flexibility to shape the output with whatever logic you need.

RABL?… It works similarly to JBuilder, so I'd call it its direct competitor, but its confusing syntax and redundant methods keep me away from it. I prefer JBuilder over RABL.

collection :@users
attributes :id, :name, :last_name, :article_id
child(:article) { attributes :title, :body }
node(:read) { |message| message.read_by?(@user) }

And to_json()?… If you only need to render specific things straight from the controller, you can use this method — it's very, very fast by itself, since you're not going through an external class (AMS) or views (JBuilder). Unfortunately, if you have a JSON object with a very large structure or you need some flexibility, you should pick between AMS or JBuilder instead.

Where to start?… JBuilder, to_json() or AMS — they're all relatively easy. I decided to start with JBuilder because it closely resembles the way you work with HTML views: you keep your @users instance variable in the controller and use it in the corresponding view.

Wrapping up

I'm not trying to impose absolute rules about what you as a developer should or shouldn't do. I'm just sharing, from my point of view, the things that worked for me and help me grow every day as a Ruby developer (like Rubocop).

In the end, you have the final word — as with RABL, which I recommend trying out; if it fits your needs, don't hesitate to use it. It all comes down to personal taste and the kind of project you're working on.

If you're interested, you can also check out (in Spanish):

• Qué es y cómo crear una API en Ruby on Rails
• ¿Cómo agregar seguridad a tu API RESTful?
• ¿No sabes cómo testear un controlador en Rails? ¡Este post es para ti!

Thank you so much for reading — if you liked the post, don't hesitate to share it and recommend it to your friends.