views:

54

answers:

2

Can you have one installation of Rails and then use it for multiple apps. For example, I would like to have the following structure:

siteroot/app1 (rails)
siteroot/subsite1 (regular static html site)
siteroot/app2 (rails)
siteroot/subsite2 (regular static html site)

and so on...

What is the best practice for this?

A: 

Rails is just a framework built on top of the Ruby language.
It sounds like you're asking how to use one server, with Rails installed, to serve multiple Rails applications. So you need to start a web service for each app:

siteroot/app1 $ script/server -p 80 -e production (+ option for daemonize server, I forget)  
siteroot/app1 $ cd ../app2  
siteroot/app2 $ script/server -p 81 -e production (+ option for daemonize server, I forget)  

I'm a bit confused by your "subapps". Why are they subapps, why can't they be rendered by the same web service that handles the main app ?

Trevoke
+2  A: 

It might be technically possible, but it's certainly not supported or intended. Convention over configuration, remember. When you make a new Rails application via rails appdir, you're making a single application, and everything in there is part of that one application. It is not an installation of Rails. Your Rails installation is off elsewhere (/var/lib/gems for me), and all that code that makes up Rails will be shared between multiple applications.

In short, the best practice is two separate apps in two seperate directories. There isn't really any reason for you to want to combine two applications. If they need to share resources or a database, it should be one app with different controllers, or two separate apps with common code distilled into a library or plugin.

meagar
I understand how Rails is installed and the idea of having many apps vs many installations. So I guess the real question is, are there any performance issues with creating so many apps as opposed to having a way to reuse some of the files? Many of the apps will perform similar functions although they are completely separate for business reasons. It seems that it wouldn't be very DRY to implement similar functionality in every app. Perhaps the answer is to pull out the reusable code into my own gems or some other reusable option?
kidbrax
Yes, the answer for large projects is to pull out reusable code into gems, and then many apps can share the gems.Your performance question is separate, that depends on your deployment environment.
Jonathan Julian
Just realized that @meager pretty much said that in his answer but thanks to all of you
kidbrax