So I have a site of sites situation I have to support and I wanted to solicit any advice people might have to support this. Basically, I have a ASP-style Web app, and we will have a number of sites that are using the core functionality of that app, but may want seriously divergent views on that functionality, as well as require some additional custom functionality. So the goal is to end up with a structure and best practices that does the following: *1) Keeps the number of hardware resources required to a minimum.* Ie. Does it make sense to build all/a number of the sites into a single rails app that just needs a set number of mongrels to be running? Or is this a recipe for disaster, and it is better to separate out each site and have it running on it''s own mongrels. How does this affect resource requirements and caching? *2) Keeps the database maintenance and resources to a minimum* Pretty much the same questions as #1. Is it better to use < 1:1 sites to db instances for resource management? Obviously you don''t have quite the freedom in customizing the database on a site by site basis if you share it amongst sites. *3) Allows for easy customization of the views and possibly some controller functionality.* So I will elaborate my thoughts on this further below, but does this mean I should put my core functionality in a Rails engine and then have each site be customized in the main app folder? Or should my views have subfolders which contain the customized content and override the partial that get used based on some domain name based setting. *4) Allows for easy maintenance and bug fixing across all sites.* What is the best way to set up SVN to support something like this? Have a main trunk and then each site be a branch? Do subfolders under the main branch for each site? ## So at this point I see the following options: *1) Turn the app into a full-fledged CMS, where everything is configurable by db/files, which allows all the sites to run in one server config.* This seems like a ton of work an ends up with way to complex code, but is best on server resources. *2) Branch the code for each client, running separate mongrels/db''s for each client.* Simplifies coding at the expense of server resources, and needing to make changes in possible dozens of branches. *3) Use a rails engine so that the base functionality is there and then customization can be layered on top in the main app branch. But each sites customizations would be a separate branch. * Eases code changes for the main rails engine functionality, but still has server resource issues. *4) Completely customize the way rendering etc looks for files so that it looks for the partials/images first in a subfolder first then defaults back.* Ie. have a folder structure like: app/views/application/[site1|site2|site3] And having default index.rhtml in application, and overriden index.rhtml in application/site1 for example (but not necessarily application/site2). This has better resource management and seems more manageable than #2 or #3 as far as code maint. ## So #1 or #4 seem to be the best choices, just not sure that #1 is within the scope of manageablilty. Anyway, if any of you out there have faced a similar situation or just have an opinion/ideas for me I would appreciate your feedback. Thanks. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---