Having two rails apps share the same models

Rails
1

Hi,

Say I have a public facing website, and a separate admin-only website
(that needs to be separate). They do need to share some, if not all,
of the models and libraries.

The simplest thing I can think of is to have the models and libraries
somewhere separate, maybe in their own git repository as a submodule,
then on deploy of each application, copy them into the app/lib
directories.

That seem reasonable?

Joe

2

Joe Van D. wrote:

Hi,

Say I have a public facing website, and a separate admin-only website
(that needs to be separate). They do need to share some, if not all,
of the models and libraries.

The simplest thing I can think of is to have the models and libraries
somewhere separate, maybe in their own git repository as a submodule,
then on deploy of each application, copy them into the app/lib
directories.

That seem reasonable?

Joe

/project
/public
/admin
/common

you’ll have to deploy them in this structure

but then add to both of your config/environment.rb

config.load_paths += %W( #{RAILS_ROOT}/…/common/app/models )

should work.

3

On May 4, 6:46 pm, Matthew R. Jacobs <rails-mailing-l…@andreas-
s.net> wrote:

directories.
you’ll have to deploy them in this structure

but then add to both of your config/environment.rb

config.load_paths += %W( #{RAILS_ROOT}/…/common/app/models )

should work.

Makes sense, I’ll give it a try. Anyone done anything like this? The
main reasons for this are:

  1. Security. Easier to protect admin section of site if it’s not
    accessible via the public network.
  2. Upgradability. We can upgrade the admin part of the site without
    affecting anything on the public one.
4

Hi Joe,

why the application needs to be “physically” separated into two
standalone Rails apps? Security concerns, separate developers, or …?

You probably set yourself for couple of troubles this way. If you
really need them to be separate, I’d suggest to put shared logic into
a standard Rails plugin.

Karel

–
www.karmi.cz

5

I have the following two URLs which are actually the same APP:

http://www.flute-fidelity.com.au/
http://www.billyhydewoodwind.com.au/

I find it’s quite easy to get rails to switch functionality based on
the URL that it gets driven from. Why not simply have two virtual
hosts pointing to the same web app, and put some webserver rules on
one for being local only, and on the other for being public only.

Then, the rails app can know whether or not to honour its admin side
or not. Makes it easier for development than messing around with
multiple apps accessing the same codebase (i’ve done that before, too,
and it’s a bit on a nightmare).

Julian.

Learn Ruby on Rails! Check out the FREE VIDS (for a limited time)
VIDEO #4 coming soon!
http://sensei.zenunit.com/

6

Have you looked into sharing models between your apps using
ActiveResource?http://railscasts.com/episodes;archive (episodes 94 and 95)
Assuming that you absolutely must separate into two applications, this
would be my recommendation. The admin side of things should be the
lower-traffic side so I’d suggest using ActiveResource there to access
the objects in the public app.

why the application needs to be “physically” separated into two
standalone Rails apps? Security concerns, separate developers, or …?
Karel does ask a good question. It’s also reasonable to use the
map.namespace options to create an admin area in the site. It could
use whatever authentication/authorization scheme you want so you could
secure it in a different way than your public site. Certainly this
would be easier than supporting separate apps.

7

I have a similar situation where I have one application that acts as a
portal to 3 other applications.
The portal application’s database is VERY bare-bones and holds the
minimum amount of information
for my shared models. (Like users)

We turned our models into a plugin and had all the apps bring in the
plugin as an SVN external.

class User < ActiveRecord::Base
unloadadable self

def self.table_name
“*YOURAPPSNAME_” + ENV[“RAILS_ENV”] + “.” + “users”
end
…
end

So far this is serving us well - there are a few gotchas (some
expected, some not expected)…
All the DBs need to be on the same machine using this approach…even
though they are different databases.

Also - it makes any changes to that plugin cascade across all your
applications - so you need to account
for the way your applications interface with those models.

One major boost we’re seeing out of this approach is the ability to
decorate models in each one of the application.
So a user may get new methods and associations in application1 - we
can easily make a UserDecorator module in our
/lib folder to give the user these methods and associations.

Have you looked into sharing models between your apps using
ActiveResource?
http://railscasts.com/episodes;archive (episodes 94 and 95)