Лучшие практики для структурирования «большого» Rails-приложения - PullRequest
17 голосов
/ 29 ноября 2009

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

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

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

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

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

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

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

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

Ответы [ 6 ]

6 голосов
/ 30 ноября 2009

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

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

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

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

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

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

5 голосов
/ 30 ноября 2009

Я бы включил все это в одно приложение, потому что вы не будете дублировать классы (модели, плагины и т. Д.) Во всех приложениях. Кроме того: запуск 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 голосов
/ 30 ноября 2009

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

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

Посмотрите на структуры авторизации, такие как Declarative_authorization или cancan .

2 голосов
/ 30 ноября 2009

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

0 голосов
/ 13 января 2011

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

0 голосов
/ 30 ноября 2009

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...