Site Architecture: One big rails app or multiple small apps

Hi,

What does everyone think regarding whether to build one large rails app
or multiple small rails apps?

For example, lets say I build an online friends site using ror, which
would contain different categories to be placed under subdomains under
the toplevel.

For example:
mysite.com: showcasing all sections, handle user registration and
login
dating.mysite.com: for general dating
intimate.mysite.com: for intimate encounters
friends.mysite.com: for general friendship

Should I make each of the above section a separate rails application?
mysite.com --> mainapp
dating.mysite.com --> datingapp
intimate.mysite.com --> intimateapp
friends.mysite.com --> friendapp

Or would it be better to create all those sections under one single
rails application such as:
mainapp/
mainapp/dating_module
mainapp/intimate

Looking to be enlightened on some pros and cons for both ways, in
regards to peformance, maintainability, development, etc.

Few things to consider in my design:

  • each section of site will share 1 database and user registration/login
    system via the main mysite.com
  • each section of the site will have many common functionalities, such
    as user data, tags, user photos. I would expect a good portion of the
    models to be the same and some of the controller. The views would be
    completely different.
  • For example, a user going to “my account” section should be the same
    across all sections as that data shared among all sections.

Thanks!

Truong-an Thai wrote:

Hi,

What does everyone think regarding whether to build one large rails app
or multiple small rails apps?

One app.

Ruby allows you all sorts of ways to share code between the similar
modules: inheritance, modules as mixins, metaprogramming, etc

If the user accounts are common and there is one database for the whole
thing then I think you’d be doing battle and going against Rails if you
had multiple applications.

Although I’ve never done it, Rails also allows ways of splitting a high
traffic application across multiple servers (db on one server, app
parts on other servers) and Capistrano can help with this deployment.

Peter

Hi Peter,

How would you split up the modules in the application? I have seen
people do nesting with routes, etc but in terms of maintanence down
the track how would someone know what is where? Hope that makes sense.

Thanks,
Carl.

On 9/3/06, [email protected] [email protected] wrote:

modules: inheritance, modules as mixins, metaprogramming, etc


Carl W.
0412218979
[email protected]

Carl W. wrote:

Hi Peter,

How would you split up the modules in the application? I have seen
people do nesting with routes, etc but in terms of maintanence down
the track how would someone know what is where? Hope that makes sense.

That’s a lot more advice than I could give. It would depend so much on
the situation and how the modules interconnect and a whole lot more.
Perhaps post a specific example and someone with appropriate experience
can give a valuable answer.

Give that that orginial post said that everything will be the same
between the modules except the views it sounds like a one app deal to
me.

Peter

To me, there is no question it should be one app.

However, I am new here, and have the same question in my mind. I don’t
know how to do it.

Anybody gives a high-light on this?

Well I can pick something simple,

say I’ve got some sort of social book marking application and with
that there is a blogging application. You should be able to move
through these applications seamlessly (i.e. single signon). And then
add to this a billing application that also shares the same user
credentials.

Any ideas?

Thanks,
Carl.

On 9/3/06, [email protected] [email protected] wrote:

the situation and how the modules interconnect and a whole lot more.


Carl W.
0412218979
[email protected]

Carl,

Single Sigon would be a different topic. If all your sites are on the
same domain or even subdomain, single sign isn’t a problem.

The true question is, should you make multiple railsapps out of this. I
think it comes down to how much you will be sharing between the
different railsapps. I would expect at least the user data to be
shared.

If you were to create multiple rails apps, then you would have to copy
code from one rails app to another rails app.

OR, you could have a “mainrailsapp”, that handles the user registraiton,
login, etc. Have your other railsapps simply redirect to this app for
login and such.

I think a really good example to analyze based on my original question
is 43things.com and 43places.com.

Obviously, they the two sites share a lot of the same funcitonalities,
such as user registration, uploading images, writing entries. What
makes me wonder is, are they running separate rails applications for
each site? There is enough custimization on each site which makes me
think it would be easier to create separate rails application, however
that would require a lot of code duplication for simliar
funcitonalities.

A pro I see for creating separate rails apps is that you could potential
have site “A” running while putting down site “B” for mainenance without
affect each other.

And what about memory usage with a single large rails app vs multiple
smaller rails apps.

Truong.

Carl W. wrote:

Well I can pick something simple,

say I’ve got some sort of social book marking application and with
that there is a blogging application. You should be able to move
through these applications seamlessly (i.e. single signon). And then
add to this a billing application that also shares the same user
credentials.

Any ideas?

Thanks,
Carl.

On 9/3/06, [email protected] [email protected] wrote:

the situation and how the modules interconnect and a whole lot more.


Carl W.
0412218979
[email protected]

Some reasons to split up the application would include:

  • User Management / Delegated Management - build it only once & abstract
    from apps
  • Ruby eventually will need to cater for the supporting a “Porlet” type
    standard which then addresses the concept of having muliple
    applicationsn (portlets) within an overall portal perhaps.
  • Authentication - build only once again & abstract from apps
  • we did this once in java based on the concept of passing off to the
    common application with appropriate session parameters (e.g. return
    link) and then handing control back afterwards. Was quite ackward from
    a security sense as there were quite a few checks and balances to take
    care of. A portlet/portal concept would be better.
  • in the case of ruby I would be inclined to have a standard mix-in
    concept for this (but leave the actual user management screens in a
    separate app)
  • Lower Deployment Risk - i.e. the ability to perform a production
    release of 1 application only without the risk of impacting another
    application. This is an issue in a large organisation who will want
    regression testing against the areas that have changed.

thats all for now…

Hey Truong-an

The true question is, should you make multiple railsapps out of this. I
think it comes down to how much you will be sharing between the
different railsapps.

yes…exactly.

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.

And what about memory usage with a single large rails app vs multiple
smaller rails apps.

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?’

Truong, I think you hit the nail on the head when you stated that it
comes down to how much code sharing there is.

As for the original question, I’m creating a site that will eventually
have about 7 very different components (mini-apps?) under one umbrella.
I’m sticking with the single RoR approach because I want to keep it
simple. I suspect that I’ll want to pull one or two of the components
out into their own app in the future, but I just don’t know right now.
So why complicate my initial development and deployment worrying about
something that might or might not happen? Yet if I see a lot of common
code I DRY it up by putting it in a plugin or a file living in the lib/
dir. Plus, with the way RoR is organized, pulling out a few
controllers into their own app will be a piece of cake. I think it
would be harder to try and ‘simplify’ multiple apps into one than split
one app into many.

Good luck with your project!
Adam

If you are looking to share alot of code, whether it be controllers,
models, views, tests, etc… A Rails Engine would be the way to go.

They are a more comprehensive system which extends upon the plugin
architecture. You can use the svn:externals feature to be able to have
a single location which all your code is stored in a central location,
then each app that utilizes that code can be very easily updated.

In addition, when it comes to customizing it based on some specific
application, you can override your Engine code for that specific
application.

Starting off with an Engine before you see that the code is indeed
central to more than one of your applications doesn’t make sense
unless it is indeed something that is common. Such as the DateBocks
library I wrote, Substruct eCommerce Engine Seth wrote, or something
similar. Whereby the majority of your code (+~80%) or so, is going to
be the same across all your apps.

You can find more info at http://rails-engines.org

-NSHB

On 9/3/06, Adam G. [email protected] wrote:

have site “A” running while putting down site “B” for maintenance without
comes down to how much code sharing there is.
controllers into their own app will be a piece of cake. I think it
would be harder to try and ‘simplify’ multiple apps into one than split
one app into many.

Good luck with your project!
Adam


Nathaniel Steven Henry Brown

Open Source Insight - http://nshb.net
Open Source Development - http://inimit.com
Open Source Training - http://osevents.com

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.

On 9/2/06, Carl W. [email protected] wrote:

Well I can pick something simple,

say I’ve got some sort of social book marking application and with
that there is a blogging application. You should be able to move
through these applications seamlessly (i.e. single signon). And then
add to this a billing application that also shares the same user
credentials.

what is social bookmarking?

user will have a controller: UserController (create a user with the
registration page, modify user preferences)
login will have a controller: LoginController
the blogging with have a couple controllers: ArticleController,
CommentController
billing sounds like an administration-only task: BillingController
maybe something for the user: PaymentController

These modules seem relatively small so it isn’t a big deal to have
them all in one app.

Study this link until it makes sense. There were lots of great blog
articles around the blogsphere when this came out

http://www.loudthinking.com/arc/000593.html

while looking at the slides watch the video too

http://blog.scribestudio.com/articles/2006/07/09/david-heinemeier-hansson-railsconf-2006-keynote-address

This helped me understand how to split up tasks in the controllers (and
views)

Peter

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.