Веду команду из четырёх человек, сервис на Hanami 2 и PostgreSQL. Бизнесу срочно нужна внутренняя админка: справочники, поиск по заказам, ручная смена статусов, к концу ноября. Писать это на Hanami руками долго. Думаю поднять рядом маленькое Rails-приложение на ту же базу, только для админки. Кто так делал, какие подводные камни?
Делали похожее: отдельное Rails-приложение для внутренних людей на общей базе. Работает, если договориться о двух вещах.
Первое: схемой владеет одно приложение. Миграции живут только в Hanami, а Rails подключается к готовым таблицам без своих миграций. Иначе через полгода две истории миграций разъедутся, и никто не вспомнит, откуда взялась колонка.
Второе: бизнес-правила. Если смена статуса заказа в основном сервисе шлёт уведомления и пишет историю, а админка просто делает update, получите заказы, которые поменяли статус молча. Поэтому всё, что сложнее справочников, админка делает через API основного сервиса, а не напрямую в базу. И отдельный пользователь базы для админки, с правами только на нужные таблицы.
А что именно долго на Hanami? Если это формы и таблицы, во втором Hanami с ними вполне можно жить. Rails рядом это второй стек на четверых: обновления, уязвимости, два набора гемов. Через год админка разрастётся, и поддерживать её будут те же четыре человека.
Вот тот случай, когда Rails правда быстрее. Админку за месяц на генераторах, остальное потом
Посчитали с ребятами: на Hanami формы и таблицы у нас недели три только на каркас, на Rails со scaffold около недели. Решили так: Rails-приложение без своих миграций, отдельный пользователь базы с чтением на всё и записью в три справочника, смена статусов через API основного сервиса, как советовал kostya.sokurov. fedya_1986, про второй стек согласна, поэтому договорились: в Rails-приложении никакой логики сверх админки, обновляем его вместе с основным сервисом раз в квартал, а если к весне админка начнёт обрастать бизнес-правилами, переносим её в Hanami. Через месяц напишу, что вышло.