О фреймворке, написанном на языке программирования Ruby и реализующем архитектурный шаблон Model-View-Controller для веб-приложений написано много. Но чем же он является на самом деле и как работает? Давайте разберемся.
С точки зрения пользователя, веб-приложение это сайт, которым он пользуется в браузере. Например Twitch, где он смотрит трансляции любимых стримеров, Kickstarter, где он может помочь реализовать чьи-то идеи или продвинуть свою, GitHub, где он вместе со своими друзьями создает что-то восхитительное. Все эти сайты, кстати, написаны с помощью Rails. Как и любое настольное приложение, веб-приложение — это определенный функционал обернутый в понятный пользовательский интерфейс.

Rails же сам по себе — это набор инструментов, который помогает нам создавать веб-приложения. Благодаря ему мы можем не вдаваясь в тонкости взаимодействия клиент-сервер и сосредоточиться на главном. Но все таки, как он работает? Рассмотрим пример.
Допустим, мы переходим по ссылке «<наш_сайт>/posts/42». После того как запрос из браузера обработается веб-сервером и будет передан Rails, он попадает в так называемый роутер, который по заранее определенным правилам решит, какая часть веб-приложения должна его (запрос) обработать. Настройки роутера хранятся в файле config/routes.rb. Для описания маршрутов в этом файле используется специальный DSL (domain-specific language — «язык, специфический для предметной области»). Этот язык обеспечивает простоту и «читабельность» при составлении маршрутов. Записи в нем выглядят следующим образом:

Rails.application.routes.draw do
 get ‘/posts/:id’, to: ‘posts#show’
end

Эта запись означает все HTTP GET запросы по адресу «<наш_сайт>/posts/<номер>» будут перенаправляться в метод show контроллера PostsController, а значение <номер> будет передано в качестве параметров. Естественно, это не единственный возможный вариант записи маршрутов. Роутинг в Rails очень богатый и гибкий, но подробнее мы его рассмотрим в следующий раз.

После прохождения роутинга, наш запрос попадает в контроллер, который располагается в папке app/controllers/posts_controller.rb в метод show:

class PostsController < ApplicationController
 def show

   @post = Post.find params[:id]
 end
end


В этом методе, мы получаем экземпляр модели Post с идентификатором, который не передан в запросе (42) и сохраняем его в переменную с именем @post. Модели в Rails по умолчанию строятся на ActiveRecord и если мы взглянем на файл app/models/post.rb мы увидим простой класс, который так же настраивается с помощью своего DSL:

class Post < ActiveRecord::Base
belongs_to :category
 has_many :comments
end

Эта запись говорит нам, что в таблице posts базы данных есть записи сообщений. Каждая запись имеет связь с записью в таблице categories через внешний ключ category_id, а также с множеством записей таблицы comments по внешнему ключу post_id в таблице comments. Как и в случае с роутингом, мы не будем сейчас останавливаться на этом DSL и пока вернемся к контроллеру.

Теперь, когда мы получили нужный экземпляр модели, наш контроллер возвращает нам представление этой модели. Для нашего случая он будет искать его в файле app/views/posts/show.html. Важной особенностью Rails в плане поиска подходящего представления является то, как он это делает. По умолчанию, он ищет примерно следующее:

app/views/<имя_контроллера>/<имя_метода>.<формат>.<шаблонизатор>

Формат определяется либо заголовком Accept HTTP запроса, либо расширением файла в запросе. По умолчанию формат считается равным html. Но, например, если бы мы послали запрос «<наш_сайт>/posts/42.txt», то представления Rails бы искал где-то в app/views/posts/show.txt. Шаблонизаторы — это инструменты, который формируют документ по шаблону с помощью входных данных. Для Rails чаще всего используется шаблонизатор ERB (Embedded RuBy). Допустим у нас есть файл app/views/posts/show.html.erb с таким содержимым:

<h4><%= @post.id %>: <%= @post.title %></h4>
<div><%= @post.body.html_safe %></div>

При формировании представления Rails сперва пропустит этот файл через ERB и получит следующий HTML фрагмент:

<h4>42: Заголовок сообщения</h4>
<div>
 <p>Это пример сообщения для нашего <b>Блога</b>.</p>
<div>


Далее этот фрагмент обернется в шаблон app/views/layouts/application.html.erb:

<html>
<head>
 <title>Наш блог</title>
</head>
<body>
 <%= yield %>
</body>
</html>


В итоге в наш браузер вернется уже полноценный HTML документ:

<html>
<head>
 <title>Наш блог</title>
</head>
<body>
 <h4>42: Заголовок сообщения</h4>
 <div>
   <p>Это пример сообщения для нашего <b>Блога</b>.</p>
 <div>
</body>
</html>


Как мы видим, процесс создания простого приложения на Rails очевиден и понятен: описали модели и маршруты, подготовили контроллеры и представления и наше приложение готово! И это еще не все, на что способен этот фреймворк.

Вот краткий список возможностей для  реализации на Rails:

1) Он написан на Ruby. Это очень элегантный язык, с помощью которого легко создаются те самые DSL, которые мы видели в роутах и моделях. Писать на нем легко и понятно, а код часто выглядит настолько естественно, что кажется что и не код, а выражение ваших мыслей на английском языке.
2) Разумное соглашение о использовании кода. Практически всегда стандартное поведение — это то, что вам нужно. Но даже когда что-то необходимо переопределить — это делается легко и просто.
3) Управление зависимостями. Rails сам по себе является гемом (gem — пакет кода для языка ruby) и в вашем проекте его функционал легко расширяется с помощью других гемов. Стоит немного разобраться и обновление любых компонентов приложения не станет для вас большой проблемой.
4) Огромное сообщество Rails разработчиков. Проект активен и постоянно развивается. Помимо добавления новых возможностей в сам Rails, имеется также огромное количество независимых проектов, которые предоставляют свои гемы.
5) Генераторы кода. Они обладают широким функционалом нацеленным на то, чтобы сократить рутинную работу до разумного минимума.
6) Механизм миграций. Вся структура базы данных описывается с помощью специального механизма, который позволяет применять ее изменения как в прямом, так и, с некоторыми ограничениями, в обратном порядке. Таким образом схема вашей базы также легко размещается в системе контроля версий, и если вы вдруг решите вернутся к состоянию базы годовой давности — это не будет для вас проблемой.
7) Разработка через тестирование. Вместе с Rails мы получаем фреймворк unit тестирования MiniTest, а сами генераторы Rails будут по умолчанию создавать нам заготовки для написания тестов. Это очень помогает принять принцип TDD (Test Driven Development) и впустить тесты в свою жизнь.
8) Помимо всего вышеперечисленного, Rails из коробки умеет организовывать хранилище пользовательских сессий (cookie), кэширование и конвейер пользовательских ресурсов (Assets Pipeline). Все это вместе дает нам ценнейший инструмент, позволяющий воплотить в жизнь любые наши смелые идеи.