Collaborative models between two Rails applications - what is the ideal solution for Workflow?

Question

I am currently working on a Rails 3 project, which is divided into four parts:

• Public website
• Administration / Backend Website
• Models
• API for accessing third-party data

Since the models are shared between the three key components, I want them not to be in the same main project, however each part needs access to the models, but I do not want to repeat the code and have different versions everywhere.

I currently have the model code in the gem, and in every Gemfile project I refer to them with the following line:

gem "my_models", :path => "../my_models/" 

However, when I deploy to our test servers for my employees to evaluate the system, I need to get the models out of the external repository, so I will change the line above as follows:

 gem "my_models", :git => "[e-mail]:username/my_models.git" 

This in itself works well, but its quite awkward in terms of “versions” (ie I need to have a version outlined every time I plan to deploy the changes to test servers), switch the line to using git instead of local and make sure i click the files correctly.

I used to use the generic git submodule, but it was just as inconvenient.

I would prefer not to build everything into one megaproject, as they tend to become monstrous and difficult to maintain, and I would also like to share the problems, if possible, so most of the changes that I made to the administration site do not have much chances to influence other components - it is obvious that models can create problems, but this is a risk that I have considered and understood.

What would people suggest there when it comes to something like that? Or, am I not mistaken about this?

Additional Information:

This application is a correspondence with an existing website that monitored the “all in one project” model - unfortunately, there are two problems here:

• The application was poorly developed - I inherited this project, and when I first took it, the loading time was ~ 2 minutes per page with one user - it has since been reduced, but still has problems in all
• We are currently at the limit of the capacity of the current site, and we expect that in the next 6 months we will need more workload. However, scaling with the all-in-one application means that we will spend resources when scaling the back end of a site that does not need it.

Essentially, there are two things I want to separate: the front end (which is a public website and API) and the back end - all I know about software development tells me that combining all of this is not an ideal solution (and past history shows me that separating the two is a good step in terms of ensuring front-end performance).

Perhaps I need to look at it from a different angle - to save models in each project and instead of sharing them between projects, have a reduced subset of functionality for each functional area (that is, the backend should know who created it but the front end doesn't really care about this, so omit this logic when reading in the model).

Answer 1

drop the model project (put the models in one of the other parts, I suggest everything that you think is “more important”), put all the projects in one repository (separate project folders) and make symbolic links to the / libs / apis / models

your code is tightly coupled together, and you often have to make changes to several projects at the same time (for example, updating models and updating APIs that use them, etc.)

One good thing about setting up single-repo-symlink is that your commits will be less fragmented and will usually be a fully functional implementation - it's easier to track errors, read history, and maintain code.

Also, when deploying, you don’t need to read from many repositories - one minute of error right there

the release process is also simpler with a model such as the branch will now have an area of ​​all projects

there are some flaws like symlinks that don't work so well on windows and something else but for me it works great

Answer 2

You can create a mountable engine containing common models and create a gem from it. This will handle name distribution issues. Another nice aspect here is that you can also share your assets.

See railscast for details .

Answer 3

You still have to manage the “versions” by pushing the changes you need to test on the remote repo, but you can use the new local Bundler 1.2 configuration

http://gembundler.com/man/bundle-config.1.html#LOCAL-GIT-REPOS

That way, it picks up your local commits and you don’t have to change your Gemfile during deployment.

Answer 4

I know this is not a solution to your specific problem. But I really suggest you combine all the projects into one. It is very common to have all of these parts in one application and there is no overhead. I think there is no inconvenient solution for this problem.

Answer 5

Does your project have enough code coverage? If so, I will try to separate the logic where it makes sense, and if the model is used in different projects, just select the one that works best and write the API on top of it.

You can then use this API to access these models (preferably using something like ActiveModel) in another project. You will still have a simple CRUD, but all the logic of the base model will be processed externally.

Remember to think carefully before cracking them. You want your domain to be closely related to every Behemoth application you create that you want to break.

Regarding engines:

I used Engines for the same problem and it helps, but I also had to change my Gemfile to either point to the local path during development by clicking on the stone and then pulling it on the current project, which is a behavior you don't like.

Answer 6

Look at the Git subtree.

This might work for you.

http://igor-alexandrov.imtqy.com/blog/2013/03/28/using-git-subtree-to-share-code-between-rails-applications/

OR

You can write a Rake task.

Example: -

 namespace :sync do desc 'Copy common models and tests from Master' task :copy do source_path = '/home/project/src-path' dest_path = '/home/project/dest-path' # Copy all models & tests %x{cp #{source_path}/app/models/*.rb #{dest_path}/app/models/} %x{cp #{source_path}/spec/models/*_spec.rb #{dest_path}/spec/models/} # Database YML %x{cp #{source_path}/config/database.yml #{dest_path}/config/database.yml} end 

See the link below.

http://hiltmon.com/blog/2013/10/14/rails-tricks-sharing-the-model/