Ruby on Rails Overview

Ruby on Rails (usually just "Rails") is a full-stack web framework written in Ruby, created by David Heinemeier Hansson in 2004. It's the single biggest reason Ruby became widely known, and it's worth understanding on its own terms — Rails and Ruby are related but distinct: you can write Ruby without Rails, but Rails is Ruby through and through.

Convention over configuration

Rails' defining philosophy is convention over configuration: instead of requiring you to wire up and configure every piece of a web application by hand, Rails assumes sensible defaults and only asks you to configure the parts where your app genuinely differs from the norm.

If a model is named Article, Rails assumes it maps to a database table named articles, with a primary key called id. If a controller is named ArticlesController with an index action, Rails looks for a matching view at a predictable path. None of this requires explicit configuration — you only override the convention when you have a genuine reason to, which in practice is rare. Compare this to frameworks that ask you to explicitly declare every route, every table mapping, and every view path by hand: Rails trades some of that explicitness for speed, on the bet that most apps don't need to deviate from the common shape anyway.

MVC: Model-View-Controller

Rails is organized around the MVC pattern, splitting an application into three responsibilities:

• Model — represents data and business logic, typically backed by a database table via Active Record (Rails' ORM). A model knows how to validate itself, relate to other models, and query the database.
• View — the templates that render HTML (or JSON, etc.) sent back to the browser. Rails views are typically .erb files, embedding Ruby inside HTML.
• Controller — receives an incoming request, talks to the relevant model(s), and decides which view to render (or what data to return).

# app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
  def index
    @articles = Article.all
  end
end

<!-- app/views/articles/index.html.erb -->
<h1>Articles</h1>
<% @articles.each do |article| %>
  <h2><%= article.title %></h2>
<% end %>

This separation keeps a codebase organized as it grows: database logic lives in models, request handling in controllers, presentation in views — rather than all three tangled together in one file.

Active Record: the ORM

Active Record maps Ruby classes to database tables and rows to objects, so you interact with the database using Ruby instead of writing raw SQL for everyday operations:

Article.create(title: "Hello Rails", body: "My first post")
Article.where(published: true).order(created_at: :desc)
article.update(title: "New Title")
article.destroy

Why Rails is associated with rapid prototyping

A combination of factors gives Rails its reputation for speed: convention over configuration removes a lot of upfront decision-making; generators scaffold a working model/view/controller/route set from a single command (rails generate scaffold Article title:string body:text); and a huge, mature gem ecosystem (via Bundler, covered in the previous lesson) covers most common needs — authentication, file uploads, background jobs — without writing them from scratch. This is genuinely why Rails became associated with startups needing to validate an idea quickly: going from an empty directory to a working CRUD web app can realistically take under an hour.

That speed comes with a trade-off worth naming honestly: Rails' "magic" (methods and behavior that appear from convention rather than explicit code) can make an unfamiliar Rails codebase harder to trace than a more explicit framework, until you've internalized the conventions. It's a genuine productivity framework for teams who know it, and a genuine learning curve for those who don't yet.

Where Rails fits today

Rails remains a mainstream, production-grade choice — GitHub, Shopify, and Basecamp (Rails' original home) all run substantial Rails codebases at scale, disproving any notion that it's only for prototypes. It competes most directly with Django (Python) and Laravel (PHP) — all three share the same "batteries-included, convention-driven" philosophy, as opposed to more minimal frameworks that leave more decisions to the developer.