What are the basic reasons a developer might choose
Ruby on Rails over any of the newer frameworks, such as
Next.js or
Vue? There are plenty of choices today; recently I looked at
Eleventy, for example, which specializes in static websites using the
Jamstack model.
The main attraction of Rails is indeed those rails — the loving embrace of opinionated software. Because Rails mirrors the development of
agile itself, you will find a workflow (and several variants) mapped out for you. The whole concept of devs blogging about development is very much a Rails thing. Just look at the wealth of material on, for example,
rspec on the topic of behaviour-driven development.
I remember in a code jam using
Devise for user authentication over 10 years ago. It’s designed to use with Rails and is still available and managed. From a business perspective, this one Rails solution might represent a stronger assurance of quality than those available from other frameworks, whose creators were still in kindergarten that long ago.
Even if your final destination is elsewhere, you can do a lot worse than start your full-stack life with Rails. Strong advocates for other frameworks may also have started with Rails in the past (that’s certainly the case with the creators of
Remix).
Continuing Our Rails Config
In our
last post, in which I showed you how to do a “full fat install” of Ruby on Rails, we were just getting into some object relational mapping (ORM). First we installed Ruby, Rails and sqlite3. We wrote a route, with a controller, and started the server. Then we created a model and our first migration (below), which is the description of a record. We are following on from this
Rails guide.
class CreateArticles < ActiveRecord::Migration[7.1]
def change
create_table :articles do |t|
t.string :title
t.text :body
t.timestamps
end
end
end
Why is it called a migration? Does it involve birds or border walls? A migration is a reference to a version of a schema or the changes to it. When we update this, we migrate from one version to another. I think the name has stuck precisely because it is slightly off key, yet memorable.
We will get an auto-incrementing primary key for free when we
create_table, so all that matters are the columns, title and body we helped define earlier for the model, when we called the generator.
Before we go on, you might have noticed that in the previous post I never configured the database. Now, sqlite is “zero configuration,” which, needless to say, will not match what you want for production. It does mean, however, that I don’t need credentials.
We can see database configuration in two places. The first is
config/database.yml.
default: &default
adapter: sqlite3
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
timeout: 5000
development:
<<: *default
database: storage/development.sqlite3
The other place is in the shell’s environment variables. The above confirms that sqlite3 will be used. If we really needed credentials, they would have to be referenced here.
Now that we have confirmed the database can probably hear us, lets run that first migration:
👁 Image
Cool, but what exactly did that do? Well, wisely the guide suggests that we plunge into the Rails console. This is like the live Ruby console, irb, but for Rails, and it groks the project’s Ruby source. Note how the completion already knows about our
Article model, and the
ArticlesController:
👁 Image
I know I can ask the model for all the existing Article objects, even though there should not be any as yet:
👁 Image
This clearly references the appropriate SQL, and believes the schema for the articles table is available. In which case, we can create an article and it should pop it in the table:
👁 Image
We can see how the object, once saved, is inserted via SQL into the table. The console is a good way to demystify ActiveRecord. But we are here to make a website, so let’s get back to the project source.
When we hit our one route, we want to fetch all the articles and then let the view show them all. This is the typical Model-View-Controller (MVC) flow; the data is in the model, the controller intercepts the REST request defined in the route, then the view shows the required data.
So the controller (i.e.
app/controllers/articles_controller.rb) needs to load the articles:
class ArticlesController < ApplicationController
def index
@articles = Article.all
end
end
So,
@articles represents a local variable, but one that the view can also read.
Now for the view; we will use the templating language ERB. We looked at examples of this in the
Hotwire article, and it is pretty simple to pick up. We replace
app/views/articles/index.html.erb with:
<h1>Articles</h1>
<ul>
<% @articles.each do |article| %>
<li>
<%= article.title %>
</li>
<% end %>
</ul>
This is the intermix of Ruby code and HTML that is both efficient, but also a bit messy for some people. Back on
http://localhost:3000/articles, this shows us:
👁 Image
You can feel the flow here; route to controller to view. Because we know we will eventually exploit all of the CRUD elements through REST, we can jump ahead a bit here and prepare all the resources at once. Rails provides a specially named
resources route that maps all of the conventional routes at once.
If we asked Rails to list all the routes defined for our articles, we get the following:
👁 Image
If we now define the
resources route for articles within
routes.rb:
Rails.application.routes.draw do
get "/articles", to: "articles#index"
resources :articles
end
We can then ask again about the routes. This time we see many more defined for us:
👁 Image
From here, you can just implement the corresponding controller methods one by one.
I think we have now gone far enough to understand the guts of the Rails system. You might be surprised at how much you can do as a developer with Ruby on Rails. Not everything has to be JavaScript-focused these days, so why not go back to the future with Rails?
See also: Return to the Rails Way: Installing Ruby on Rails in 2024
