Okay seems like mixed opinions and really been up to each individual’s
project.
I think I left out a few important things when stating my original
question, so I hope to be more clear this time to get more precise
feedback from everyone. I think the specific example here can be useful
by many developers out there.
This is bit long, but it is important to understand the nature of the
application itself.
Lets Assume few things first:
Site A and Site B, are very similar sites, but just different themes.
For example, “43things.com” and “43places.com”.
Assume that two sites are under one domain using subdomains (to avoid
any single-sign-on complications).
They will share the same database (but can have different tables).
For example, the ‘user’ table will definitely be shared since we want
users to move across siteA and siteB seamlessly once registered.
However, lets look at site functionalities such as entries, comments,
photos, etc. The model and controller logic between Site A and Site B
for entries/comments/photos could pretty much be the same. The views
will look different as we want to present them as different sites, and
we could use localizations to change the site text.
Now, I am thinking of storing the entries/comments data for site A and
site B in SEPARATE TABLES. For example I can have, tables:
‘site_a_entries’, ‘site_b_entries’
‘site_a_comments’, ‘site_b_comments’,
‘site_a_photos’, ‘site_b_photos’
And so on…
Lets break down the two paths:
*** MULTIPLE APPS ***
My approach would simply be to develop siteA first with all the
functionalities and such complete, which may also use a few plugins,
gems, etc (localization, fileColumn, acts_as_taggable, etc). Site text
would be handled using a localization file. Look and feel with external
css file. Specific tables can be set for this site via set_table_name
on the model.
Now, for siteB, I simply create new railsapp and copy siteA files over.
All I have to do at this point to complete siteB is:
- modify each specific model, such as entries/comments/photos,
set_table_name value so that it points to correct table for this site.
(based on my intention of using separate tables above).
- add the specific table for this site, such as ‘site_b_entries’,
‘site_b_comments’
- modify the text in localization file
- modify the css file to change color and themes
- modify the views to present data differently
So this would be fairly easy approach in terms of implementation. Don’t
have to worry about tossing in logic to determine which activerecord
model to use in the controllers and which specific tables to use in the
model, which css to use, which localization to use.
But the cost is maintainability. I basically have two copies of the
same model/controller code, and plugins/gems used across both sites.
Not to mention, I might have a 3rd rails app, to handle the common
login/user account which also acts as the ‘main’ site app.
Changes to site header/footer will require changes to 3 files in 3 apps
for example.
*** ONE RAILS APP for both sites ****
This approach is what is complicating me.
I could initially create the two sites using modules, such as “script
generate controller siteA/entries” and “script generate controller
siteB/entries.” So controllers/views will be grouped appropriately.
However, I don’t think there are clean ways to pack models in modules.
Now comes the specific tables for each site. How would we group the
activerecord models? Would it even be possible to share activerecord
model code, that acts on different tables? What about inside
controllers which needs to use a particular activerecord model?
Should I even bother with using separate tables for entries between
siteA and siteB? (1 million rows in one table vs. 500K rows in each of
two tables).
I’ve just read about rails 1.1 polymorphic models…which may work for
this scenario, but it still packs all the model types into a table
representing the collection. So you still end up with 1 million rows in
addition to the 500K rows for each site specific table.
I can imagine having a lot of code to do this in the controllers,
models, etc.
if subdomain == ‘siteA’
…
if subdomain == ‘siteB’
…
Maybe some metaprogramming may help in this?
Or, perhaps I could just roll out one app still, but do not share any of
the
model/controller code. Still a lot of code duplication but no messy
logic to determine which activerecord model to act on. Would still have
to manage which localization or css template to use based on subdomain
info.
So you see the complication and I hope it is clear now where my problem
is =).
In Summary:
** Multilpe Rails App = Easier implementation but require code
duplication, more management.
** One Rails App = More difficult implementation, maybe less code
duplication, less management.
Thanks in advance for all suggestions.
Truong-An.
Zachary H. wrote:
On Sep 3, 2006, at 10:17 PM, Adam G. wrote:
A pro I see for creating separate rails apps is that you could
potential
have site “A” running while putting down site “B” for maintenance
without
affect each other.
why is that a pro? How many times do you have to take a site down for
maintenance? maybe 5 min a month? Same goes with memory. Why make a
major architecture decision based on some far off ‘what-if?’
Obviously I can write only for myself, but it’s not the planned
downtime that introduces the pain. It’s the unplanned downtime when
I’ve wished that I had two apps.
That said, on one of my projects, I’ve recently consolidated four
apps into one. I had admin, www, and two other subdomains, each as
its own Rails app. I even had a shared_models directory that each of
the apps added to their load paths (which means it was five things in
subversion, not just four). The setup became unwieldy. Looking
back, it was a very poor design for this application.
I can’t say there’s never a time to have separate apps, but I would
think long and hard about my reasoning before making that design
decision again (especially if the apps share the same database(s)).
Ditto NSHB on looking into Engines.