Что такое Dry-rb, и как он поможет с Ruby приложением там, где не может помочь Ruby on Rails

Я работаю в стартапе. Делаем самый прибыльный майнинг-пул с умным алгоритмом переключения. Сам пул написан на языке программирования Go, а для внутренних сервисов используем Ruby. Приложения крутятся в контейнерах, используется микросервисная архитектура. Несмотря на то, что стартап, мы стараемся не забывать о качестве кода и используем TDD: лучше спать меньше, но спокойно.

Почему нам не подходит Ruby on Rails?

С увеличением количества сервисов всё более явным становилось, что Rails, несмотря на простоту и скорость разработки, в нашем случае создаёт больше проблем, чем решает. Ниже несколько примеров сложностей, с которыми мы столкнулись.

Усложнённая архитектура

Во-первых, наши сервисы намного больше похожи на простые программы, нежели на традиционные Rails-приложения. Типичные задачи – считать статистику, мониторить сеть блокчейна, вычислять награды пользователей и отправлять транзакции. Пример API – список транзакций пользователя. Получалось, что внутри папки app появился какой-то огромный мир. Это было поддерживаемо, но мысль о том, что где-то мы свернули не туда, не покидала.

Сложности в использовании тредов

Другая проблема, с которой мы столкнулись – асинхронность. Мы много используем в коде треды, и если не выполнять preload всего приложения, регулярно получали ошибки autoload. С этим можно мириться, да и от предзагрузки приложения в тестовой среде никто не умирал. Но я считаю, что такой проблемы не должно быть в принципе – треды и без такого не дают заскучать.

Неиспользуемые зависимости

Нельзя не упомянуть большой итоговый вес приложения. Сейчас от пуша в master до развёртки новой версии на стейдже у нас проходит 50 секунд. За это время успевают пройти тесты, собирается и отправляется в registry образ. Раньше этот же цикл занимал минимум 4 минуты. Другим бонусом стало то, что теперь тесты и консоль загружаются за секунду. Очень приятная мелочь в повседневной работе, как оказалось.

Высокое потребление памяти

Наконец, мы стали банально упираться в память. Мы держим по два воркера каждого сервиса, со временем это стало достаточно затратно. Теперь же в среднем сервисы потребляют в 8 раз меньше памяти, чем они же, написанные на Rails.

Как мы решили свои проблемы?

Учтя всё вышеперечисленное и множество других мелких сложностей, было решено перейти на стек от сообщества dry-rb. Ruby on Rails же мы оставили для API-heavy сервисов, которые было долго переписывать. Мы не считаем, что Rails мёртв, он лишь не подходит для наших задач.

Ruby on Rails подходит для множества задач, и мы поможем разобраться, в каких случаях стоит использовать Rails, а в каких нет. Выбрать ментора

Данное сообщество разрабатывает множество гемов, по их мнению помогающих создавать лучшие приложения. Все они решают какую-то узкую проблему и могут быть интегрированы в уже существующее приложение. Полный список гемов, которые они разрабатывают, можно увидеть на странице организации на Github.

Теперь в своих проектах мы используем большую их часть: dry-system, dry-web, dry-transaction, dry-validation, dry-types, dry-struct, dry-monads. Этим мы решили проблемы, которые я описал выше. Но это далеко не всё, что мы получили. Приложения стали мало весить, делятся на полностью изолированные компоненты и проще тестируются. Увеличилась общая компетенция команды, появился дополнительный интерес к работе. Последнее я считаю важным фактором: горящие глаза коллег – залог отличной атмосферы в офисе. Подробнее о том, как мы используем данные решения в своих проектах, можно прочитать в следующих частях этого цикла:

Как организовать запуск Ruby приложения с Dry-system