Rails приложения архитектура и общие настройки

Question

Итак, я начинаю на проект компании, который будет иметь несколько компонентов:

На первый ...

1. Список заданий создания профиля
2. клиента и управления
3. Администрирование и доступ пользователей (логин, регистрация, роли и т. Д.)

затем ...

1. сообщений
2. Расписание
3. Базовая отчетность

путь позже ...

1. Более глубокий анализ и би

мне интересно, если это делает смысл для каждого элемента маркера собственный проект рельсов, автономный и модульный (если это действительно так); или если это просто лучше, чтобы он был в одном приложении. Я мог представить себе ситуацию, когда каждый модуль мог бы работать так независимо друг от друга, что ему не нужны остальные (за исключением функциональности пользователя) и другая ситуация, когда все модули будут использоваться вместе.

Мне кажется, что многие задачи могут быть обработаны с более легким фреймворком, таким как Sinatra (а затем физически под управлением рельсов). Также кажется, что накладные расходы будут иметь много накладных приложений на сервере. Но я не полностью осознаю все плюсы и минусы для работы по каждому сценарию.

Я знаю, что это своего рода общий вопрос, который неизбежно должен получить много ответов «это зависит» (и это справедливо). Я искал мнения/примеры того, как вы настраиваете этот тип/свой вид проект в рельсах. Я квази-ноб, будь осторожен.

Заранее благодарен!

Answer 1

Вообще-то я считаю, что сайт станет подходящей целью для приложения Rails. Каждая часть приложения может иметь собственные пространства имен в приложении, поэтому приложение имеет внутреннюю структуру, но все они должны быть одним приложением. Рассмотрим такие вещи, как сеансы, где вы хотите, чтобы пользователь заходил в систему и использовал любые функции сайта, который вы хотите. Вы хотите, чтобы эти сеансы были в одном приложении без участия пользователя в разных разделах.

Сказать, что если существует сложная или расширенная функциональность, не являющаяся частью архитектуры MVC (скажем, говорящий с внешним API, интеллектуальный анализ данных и т. Д.), Вы можете компенсировать это отдельному проекту и включить его как драгоценный камень в вашем приложении. У вас все равно будет одно основное приложение Rails, которое включает эти Gems.

Возможно, вам также понадобится объединить часть вашего проекта в многоразовый механизм Rails, который можно загрузить в несколько проектов. Например, Devise обрабатывает логин и управление пользователем. Это движок Rails, связанный как Gem, который вы включаете в свой проект.

Другой пример от Meducation (на одном из моих сайтов).Я в процессе извлечения нашей системы отслеживания электронной почты в its own Rails engine, поскольку я чувствую, что ее функциональность сидит вместе с Meducation и не является ее основной частью. Затем я могу использовать его и в других проектах.

В вашем конкретном примере, я думаю, ваши требования подходят для одного приложения Rails.