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.
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.
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.
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.
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
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.
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.
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)).
