Содержание
Rails выбирают ради одного — скорости, с которой меняется продукт. На нём работают GitHub, Shopify, Airbnb, Zendesk и другие сервисы — их перечисляет официальный сайт фреймворка. Код открыт под лицензией MIT, но разработка на Ruby on Rails всё равно заказная: дороже старта на готовой CMS, а после запуска нужен Ruby-разработчик.
Откуда берётся скорость
Один из ключевых принципов Rails — соглашения вместо настройки. Где лежат модели, как называются таблицы, как устроены маршруты и тесты, решено заранее, и команда не тратит на это обсуждения. Генераторы создают каркас сущности одной командой, а в самом фреймворке уже есть почта, фоновые задачи, веб-сокеты, хранение файлов и защита от типовых атак. Первые экраны можно показать на ранних этапах и собрать отзывы пользователей, пока менять ещё дёшево.
У скорости есть условие: соглашения нужно соблюдать. Приложение, где каждый раскладывал код по-своему, теряет это преимущество и становится обычным заказным проектом, только на более редком языке.
Где Rails выбирают
Чаще всего — в продуктовых командах: стартапы, внутренние сервисы, платформы с подпиской, маркетплейсы. Там важнее быстро выпускать новые функции, чем экономить на каждом сервере. Rails в России используют заметно реже: вакансий с ним на hh.ru меньше, чем с Django или Laravel. Если приложения ещё нет и Ruby-разработчиков в штате тоже, компании в Самаре стоит сравнить варианты до старта.
Rails без лишней инфраструктуры
Восьмая версия сделала выкладку проще. Kamal 2 разворачивает приложение на обычном Linux-сервере, а очереди, кэш и веб-сокеты по умолчанию работают на той же базе данных. Для небольшой команды это один сервер у выбранного провайдера вместо связки из приложения, Redis и отдельной платформы для выкладки. Когда нагрузка вырастет, очереди и кэш можно перенести на отдельную базу или сервер.
Как не остаться без разработчика
Главный риск здесь не в технологии, а в людях. Поэтому с первого дня держим приложение в рамках соглашений, пишем тесты на ключевые сценарии и ведём список мест, где пришлось от соглашений отступить. Обновляем фреймворк раз в год, пока разрыв между версиями небольшой. Тогда новому разработчику будет проще войти в проект, кто бы им ни стал.
Проверить, подходит ли Rails вашему продукту, проще всего на небольшом каркасе с реальными данными: он покажет и темп работы, и то, как фреймворк ложится на вашу предметную область.
