Static Request/ Routes/ HTTP workflow/ Database Migration

To get Rails saying “Hello”, we need to create at minimum a route, a controller with action, and a view. A route maps a request to a controller action. A controller action performs the necessary work to handle the request and prepares any data for the view. A view displays data in a desired format. Routes are rules written in a Ruby DSL (Domain-Specific Language). Controllers are Ruby classes, and their public methods are actions. And views are templates, usually written in a mixture of HTML and Ruby.

Before we dive into the code and routing configurations, it helps to know how HTTP works at a high level. Below is the flow that takes place when a user attempts to go to a page on a Rails application:

  1. A URL is entered into the browser; this is the HTTP request

Adding a route to our routes file, config/routes.rb :

Rails.application.routes.draw do
get "/articles", to: "articles#index"

note: Anytime we make routing changes we need to restart the Rails server!

The route above declares that GET /articles requests are mapped to the index action of ArticlesController. To create ArticlesController and its index action, we'll run the controller generator:

rails g controller Articles index --skip-routes (since we already have an appropriate route)

This will generate several files, but the most important at that point is the controller file at app/controllers/articles_controller.rb:

class ArticlesController < ApplicationController
def index

The index action is empty. When an action does not explicitly render a view (or otherwise trigger an HTTP response), Rails will automatically render a view that matches the name of the controller and action. The index action will render app/views/articles/index.html.erb by default. Add:

<h1> Hellow world </h1>

to see the text on your localhost/articles!

Explicit rendering — for explicit rendering, Rails lets you dictate which view file you want to have the controller action mapped to.
Implicit rendering — for implicit rendering, Rails follows a standard convention that automatically looks for the view file with the same name as the controller action.

To define a model, use the model generator:

rails generate model Article title:string body:text

Model names are
singular because an instantiated model represents a single data record. To help remember this convention, think of how you would call the model’s constructor: we want to write, not

Database Migrations

Migrations are used to alter the structure of an application’s database. In Rails applications, migrations are written in Ruby so that they can be database-agnostic.

class CreateArticles < ActiveRecord::Migration[6.0]
def change
create_table :articles do |t|
t.string :title
t.text :body


The call to create_table specifies how the articles table should be constructed. By default, the create_table method adds an id column as an auto-incrementing primary key. To run the migration:

rails db:migrate

Showing a List of Articles:

In app/controllers/articles_controller.rb :

class ArticlesController < ApplicationController
def index
@articles = Article.all

in app/views/articles/index.html.erb :


<% @articles.each do |article| %>
<%= article.title %>
<% end %>

The above code is a mixture of HTML and ERB. ERB is a templating system that evaluates Ruby code embedded in a document. Here, we can see two types of ERB tags: <% %> and <%= %>. The <% %> tag means "evaluate the enclosed Ruby code." The <%= %> tag means "evaluate the enclosed Ruby code, and output the value it returns." Anything you could write in a regular Ruby program can go inside these ERB tags, though it's usually best to keep the contents of ERB tags short, for readability.

hint: Since we don’t want to output the value returned by @articles.each, we've enclosed that code in <% %>. But, since we do want to output the value returned by article.title (for each article), we've enclosed that code in <%= %>.

Here’s what happens:

  1. The browser makes a request: GET http://localhost:3000.