Лучшая практика для структурирования приложения "большой" Rails

Мой вопрос здесь заключается в поиске лучшей практики, общих советов и понимания, а не решения конкретной проблемы.

Я нахожусь на ранних стадиях планирования проекта Rails, который я считаю довольно большим. На своем самом простом уровне он предлагает пользователям CMS для куки-резаков. Поэтому пользователи регистрируются и выбирают субдомен и получают довольно простой веб-сайт с CMS.

Поэтому у всего приложения есть около 4 разных "сторон":

  • Торговый сайт, продающий продукт конечным пользователям - www.myapp.com
  • Центральная область администрирования, в которой сотрудники могут регистрироваться и управлять учетными записями и т.д. - www.myapp.com/superadmin
  • Собственные веб-сайты пользователей - subdomain.myapp.com
  • Административная область пользователей /CMS - subdomain.myapp.com/admin

Итак, действительно, что я ищу, это лучшая практика для структурирования приложения. т.е. все ли оно должно быть свернуто в одно огромное приложение или должно быть разделено на более чем 2 (или более) небольших приложения?

При развертывании в качестве одного приложения я могу видеть проблемы, связанные с маршрутизацией, так как веб-сайт продаж и веб-сайты пользователей будут нуждаться в корневом пути, плюс я не хочу, чтобы маршруты, которые я установил для веб-сайта продаж, были доступны через пользователей 'веб-сайтов. Можно ли что-либо сделать либо в Rails, либо на уровне Apache (mod rewrites?), Чтобы не смешивать маршруты?

Если вы делитесь на 2 или более приложений, как вы получаете приложения, использующие одну и ту же базу данных? Это даже хорошая идея? Есть ли какие-либо выгоды от разделения приложения (например, изолирование проблем в одной области приложения, а не сведение всего)?

Я понимаю, что это сообщение поднимает довольно много разных вопросов, но оценивайте любые советы и прозрение, которые вы можете мне дать.

ОТВЕТЫ

Ответ 1

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

Недостатком является то, что у вас действительно нет изоляции, поскольку все ваши приложения привязаны к одной базе данных. В конечном итоге вы столкнетесь с проблемами масштабирования с вашей базой данных, но начните с простой базы с помощью одной базы данных. Одной из стратегий для масштабирования позже было бы добавить рабочую базу данных, которую используют клиентский сайт и приложения для основного сайта, в то время как приложения-администраторы используют master db. Это вместе с TON кэширования доставит вам довольно далеко.

Нет ничего плохого в том, что несколько приложений с рельсами получают доступ к одному db, однако вам понадобится способ совместного использования общего кода в ваших приложениях. Ваши модели по большей части. Я сделал это раньше, бросив все мои модели в плагин, который я разделяю как подмодуль в git или как внешний в svn. Наличие отдельных приложений сделает каждое приложение меньше и проще в обслуживании.

Однако, где вы сохраняете свои миграции? Где вы тестируете свои модели? Я бы выбрал приложение superadmin. Кроме того, вы вносите изменения в модель или схему, и теперь вам нужно проверить 2-4 приложения и убедиться, что они все еще работают!

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

Во всяком случае, отдельные приложения устанавливают вас для SOA, но вам не нужно прыгать за пределы одного db, чтобы начать.

Ответ 2

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

Компиляция в одно приложение устраняет эту проблему. Чтобы проблема между сайтом продаж и сайтом пользователей имела разные корни, которые можно решить, как упоминалось ранее, subdomain_fu. Позвольте мне расширить пример кода из приложения, которое у меня есть:

map.with_options :conditions => {:subdomain => 'logs'} do |admin|
  admin.resources :channels do |channel|
    channel.resources :logs
  end
  map.root :channels
  map.connect ':id', :controller => "channels", :action => "show"
end

Как мы видим здесь, :conditions для метода with_options устанавливает :subdomain как logs, что означает, что все, что входит в logs.mysite.com, будет выполнять эти условия и поэтому будет маршрутизироваться таким образом.

Далее в этом файле маршрутизации у меня есть все остальное, завернутое в аналогичный блок:

map.with_options :conditions => {:subdomain => nil} do |admin|
  # shebang!
end

Все, что происходит с mysite.com, будет идти на эти маршруты.

Наконец, компиляция всего этого в одно мега-супер-гипер-приложение устранит проблемы с совместным использованием базы данных.

Ответ 3

Самая большая проблема, которую я вижу с разделением на несколько приложений, заключается в том, что вы теряете гибкость. Что произойдет, если в будущем ранее административная задача (например, загрузка типа файла) станет "пользовательской задачей"? Вам нужно будет перемещать код из одного приложения в другое.

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

Взгляните на рамки авторизации, такие как declarative_authorization или cancan.

Ответ 4

Ну, так как никто другой не высказался, я бы посоветовал вам кое-что прочитать на сервис-ориентированной архитектуре. Книга Enterprise Rails от Dan Chak содержит некоторые замечательные материалы по этому вопросу, и вы можете многое прочитать в Google Книгах. Попробуйте главу 13, здесь. Я думаю, что это положит вас на правильный путь.

Ответ 5

Я вижу, что проблема, с которой вы сталкиваетесь, - это попытка создания приложения, которое будет иметь различные поддомены, поэтому account_manager плагин может решить вашу проблему.

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

если вы думаете о том, чтобы иметь их под одной базой данных, это довольно просто в рельсах, использующих connection_connection.

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

http://www.railslodge.com/plugins/1113-subdomain-fu

Ответ 6

Что касается моих исследований, большинство компаний в высокой степени выбрали SOA с несколькими базами данных. Вот ссылки на некоторую информацию о том, как Связано в и EBay подумайте об этом. И, чтобы эхо PreciousBodilyFluids, я настоятельно рекомендую книгу Enterprise Rails от Dan Chak.