title: Shared models between two Rails apps - what is the ideal solution for Workflow?
body: <p>I am currently working on a Rails 3 project that is divided up into four parts:</p>
  
  <ul>
  <li>The public facing website</li>
  <li>The administration website/backend</li>
  <li>The models</li>
  <li>The API for third party data access</li>
  </ul>
  
  <p>As the models are shared between the three key components I want to keep them away from being in one main project, however each part needs access to the models, but I don't want to repeat the code and have different versions everywhere.</p>
  
  <p>Currently I have the model code in a gem, and in each project's Gemfile I am referencing them with the following line:</p>
  
  <pre><code>gem "my_models", :path =&gt; "../my_models/"
  </code></pre>
  
  <p>However when I deploy to our test servers for my co-workers to evaluate the system on I need to pull the models from an external repository, so I swap out the above line with the following:</p>
  
  <pre><code>gem "my_models", :git =&gt; "git@private.repository.com:username/my_models.git"
  </code></pre>
  
  <p>This in its self works well, but its quite clunky in terms of 'versions' (i.e. I need to bump the version every time I wish to deploy the changes to the test servers), switch the line over to use git instead of local, and make sure that I'm pushing the files properly.</p>
  
  <p>Previously I was using a shared git submodule, but this was just as awkward.</p>
  
  <p>I would rather not build everything into one mega-project, as these tend to become monstrous and difficult to maintain, and I would also like to separate concerns if possible, so any changes I make to the administration site doesn't have much of a chance to impact the other components - obviously the models have the potential to cause issues, but that is a risk I have considered and understand.</p>
  
  <p>What would people out there suggest when it comes to something like this? Or, am I going about it completely the wrong way?</p>
  
  <p><em>Some additional background:</em></p>
  
  <p>This app is a rewrite of an existing website which followed the model of 'lump everything into the one project' - unfortunately there are two issues here:</p>
  
  <ol>
  <li>The app was badly developed - I inherited this project and when I first picked it up the load times were ~2 minutes per page with a single user - this has since been reduced but still has issues throughout</li>
  <li>We are currently at our capacity limit of the current site and we anticipate that we will need to take on more load in the next 6 months - however scaling out with an 'all in one' app means we'll be wasting resources on scaling out the back end of the site which doesn't need it.</li>
  </ol>
  
  <p>Essentially there are two things I want to separate - the Front end (being the public website and the API) and the back end - everything I know about software development tells me that combining all this together is not an ideal solution (and past history shows me that splitting these two is a good move in terms of ensuring front end performance).</p>
  
  <p>Perhaps I need to look at this from another angle - keep the models in each project, and instead of sharing them between projects have a cut-down subset of functionality for each functional area (i.e. the backend needs to know who created a post, but the front end doesn't really care about that, so omit that logic when reading in the model).</p>