8

Our company started out with a single product, a rails app backed by some java services, then decided they wanted another product that was initially considerably different than the first, but as time has gone on we've realized they are starting to converge, and making a code change to one requires a similar code change to the other for a new feature/bug fix. This is obviously becoming a pain.

In some cases we have gems that share some of this functionality but it goes beyond ruby into javascript, css etc..

So I'm tasked with merging these two apps into one codebase. I think eventually we'd like it to be a single app with permission based role access but that will come much later.

My first thought to quickly put them together is to create two rails engines and share common libs between them. I think this is the quickest way to combine the code, find common sections and start sharing.

My first problem though is how to route between the apps. One app uses a single domain name that never changes, the other app has many domains. Can someone suggest how I might route a particular request to a particular app so they can remain separate to start whilst sharing a common codebase of libs?

Or, if anyone has other suggestions as to a way to combine these apps I'm all ears.

They're both Rails 2.3.10 apps running JRUBY 1.5.3, but we're open to possibly upgrading to Rails3 if that would make things significantly easier or cleaner (ie with better Rack integration)

I haven't done any Rack programming but never hurts to learn if that will make our lives easier.

Fábio Batista
  • 25,002
  • 3
  • 56
  • 68
brad
  • 31,987
  • 28
  • 102
  • 155
  • Rack would be a deployment solution and probably isn't the solution here. – Chirantan Nov 19 '10 at 09:18
  • rack is the middleware right? i was thinking that it might intercept the request and route appropriately? but again i don't know much about it – brad Nov 19 '10 at 14:35

2 Answers2

2

You should avoid sharing code on server level, best to do that would be building libraries including common code base and use them during development. Probably the best shoot would be using helpers as it is easiest way to provide modules that provide functionalities all over your code.

Regarding rewriting functionalities to one application, choose that one with bigger set of ready code as a base. It should be possible to migrate code per method using web server supporting url rewriting. I thought of using apache with mod_rewrite. So the plan would be:

  1. Setup both applications to be accessible through one apache.
  2. Chose one method that is similar in both and rewrite it in one application to support both applications requirements.
  3. In apache add a mod_rewrite rule to redirect traffic to one application only on this action.
  4. Go to point two till everything is rewritten.
  5. Remove old application and adjust routing/mod_rewrite to use the one application

You do not have to use apache, there should be other web servers supporting url rewriting.

I was thinking of using this algorithm to rewrite our application to rails 3.0.

mpapis
  • 52,729
  • 14
  • 121
  • 158
1

Your idea of using engines is what I would suggest.

For routing, I would handle it outside of Rails.

For instance, you would do the following in nginx:

server {
    # Match only one host.                                                      
    listen 80 default;
    server_name YOUR_SINGLE_APP_DOMAIN;

    location / {
        upstream YOUR_SINGLE_APP_RAILS;
    }
}


server {
    # Fall thru and match any other host.                                                      
    listen 80 default;
    server_name ~^.*$;

    location / {
        upstream YOUR_MULTI_DOMAIN_APP_RAILS;
    }
}
Rafi Jacoby
  • 354
  • 1
  • 6
  • Can you explain the upstream part? I've never used this with nginx. Also, I understand matching the domain and proxying appropriately, but I want my two apps to be contained in one rails app, so according to this I suppose my routes between the two rails engines need to be unique? I was kind of hoping they could share certain routes, but would be routed to the correct action based on the domain. – brad Nov 24 '10 at 20:50
  • I guess I went the nginx route b/c of what you were saying about domains, which is something I'd handle outside of Rails usually. As far as upstream, you just define an endpoint (or more than one) that handles requests. In nginx+passenger: "upstream my_rails_app { server 10.1.2.3:8000; } server { listen 10.1.2.3:8000 etc. etc." – Rafi Jacoby Dec 08 '10 at 23:05
  • this is essentially what we ended up doing – brad Apr 29 '11 at 11:51