CODEWITHSUNDEEP
ruby-on-railsdeployment
tesserakt
tesserakt

Reputation: 3331

Share visual assets along with some controllers between two rails apps?

I have two rails apps that I am thinking about merging into one because they share a similar layout. Right now there is a script in one app that pulls the resources from the other app (including a base controller) into the second app. There are a few ways I have been thinking about doing this:

  1. Merge the apps with namespaces and upon deploy have a script that creates two separate RPM packages (this is for deployment on CentOS/RHEL) with the appropriate files in it
  2. Run one app as the engine of another. Put all the shared controllers and visual assets into the top-level app. Upon deployment rip rip out the engine if I don't need it. (i.e. if it is just the first app and I don't want to give the code of the second app)
  3. Create a GEM with the common controllers and CSS/JS and find a way to inject it into each running app.

Any thoughts/ideas? I am thinking of going with number 1 as it will probably be the easiest for development (2 would be easier for deployment I think)

Upvotes: 2

Views: 629

Answers (4)

ndp
ndp

Reputation: 21996

Most importantly, I'd recommend not merging the apps. The scenarios of modifying the package on deployment to separate the two apps is error prone, and counter to current quality control procedures-- you want the code you develop to match the deployed app as much as possible.

Given that, you want to look at the different modularity approaches. There are actually lots of options for sharing code:

  • gem
  • plugin
  • library code included with a git submodule or equivalent
  • rails engine
  • separate deployed app

Probably a shared engine packaged as a gem is the nicest way to go, but it requires you be on the right version of Rails to get the full benefit. Even without an engine, you can get this to work... it'll just take a little more setup.

By "separate deployed app", I mean a third application that has the shared functionality. This may be the needed resources (CSS, JS), and can even be portions of the pages (loaded dynamically). This is potentially a funky solution, but I've seen it work in the right situation.

And any of these solutions requires a bit more effort on the developers' part... but in the end it's better the deployment troubles you'd get by mergine the code bases

Upvotes: 0

Marnen Laibow-Koser
Marnen Laibow-Koser

Reputation: 6337

How about 4: make three engines (or gems, or engines encapsulated in gems): one for the common stuff, and one for each application's unique stuff?

Upvotes: 2

jcnnghm
jcnnghm

Reputation: 7432

Have you considered creating an engine with the common controllers, css, and js, then packaging the engine as a gem. When you are working locally, you can have both apps point to a shared development copy of the gem using bundler. To deploy, package the gem with each app, and deploy the whole thing. There are a lot of benefits to doing it as a gem, like the ability to have different versions of the gem in the future so you don't have to update both apps at the same time.

This seems like a pretty decent engines guide: http://www.themodestrubyist.com/2010/03/05/rails-3-plugins---part-2---writing-an-engine/.

I'd be very leery of it, and would probably go with the above approach, but you may consider using symlinks to permanently pull files into one or the other of the projects. I think it's a bad idea, but in some narrow cases it might make sense. It really depends on your exact situation since it's kind of a nasty hack, but nasty hacks can sometimes solve specific problems eloquently.

Upvotes: 1

Seamus Abshere
Seamus Abshere

Reputation: 8516

At Brighter Planet we do (3). Our shared layout gem supports both Rails 2 and Rails 3.

In particular you'll want to look at:

Upvotes: 3

Related Questions