Rails and Angular2 development — why you should use a monorepo.

At Renuo we started since 2016 with the development of Rails and Angular2 applications. These two technologies work perfectly together in case you want to develop a SPA. (I’m not going to explain how and why in this article).

There are some points that, nevertheless, we haven’t solved so far and that constantly grind my gears.

Maintain 2 git repos — have 2 Pull Request — feel double pain

We keep each layer on a different git repository and, even if this seems like a perfect reasonable idea, it brings many pain points:

If I make a change both in Frontend and Backend, for example, they cannot be merged because they depend on each other. The situation is very simple: imagine you change your API and instead of returning a createdAt attribute you now return a createdOn attribute. The steps would be:

  1. Make a new version of the API where you return the new attribute and keep the old one in the previous version.
  2. Make a Pull Request
  3. Code review
  4. Deploy
  5. Change Frontend to use the new version of the API
  6. Make a Pull Request
  7. Code Review
  8. Deploy
  9. Remove old version of API from the Backend
  10. Make a Pull Request
  11. Code Review
  12. Deploy

But we are not developing a public API and our Backend is used only by our Frontend so we can simplify the process:

  1. Replace the attribute in the Backend
  2. Open Pull Request
  3. Code Review (DO NOT MERGE!)
  4. Replace the attribute in the Frontend
  5. Open Pull Request
  6. Code Review (DO NOT MERGE!)
  7. Quickly press the merge button on both Pull Request and deploy the new version of both Backend and Frontend.

Easy, right? Well…no.

You have two open two Pull Requests, you have two run two CIs, you need to receive two code reviews. You feel pain.

You end up with this:

me opening a pull request and feeling pain
my colleague opening a pull request and feeling pain

We cannot run acceptance tests

Running acceptance tests is very difficult. If you consider the situation described on the previous paragraph you can imagine that acceptance tests should use the correct branch from each repository. So if I have a feature/3000 branch on Frontend (which requires also the branch feature/3000 on Backend), how do I run my acceptance tests?

Against which branch?

Maybe you have a solution. We don’t.

That’s why we run the acceptance tests only on the develop or master branch (we follow gitflow), but even then, stuff may break if you don’t merge fast enough on all layers.

Team is split in Frontend and Backend

It’s much easier to have your team split on Frontend people and Backend people. That’s a bad thing.

Our proposal: one git repo to rule them all

After some investigation I found out that word: “monorepo” and I realised that many people already listed many of the benefits you can have.

To make a concrete example follow this link and watch at the repository and the corresponding Travis configuration.

My suggestion is to place both your Backend and Frontend in a Git Repository. Simple and stupid.

You’ll immediately gain many advantages:

  1. You can run acceptance tests again!
  2. You can update your APIs with one Pull Request, one code Review and one deploy! Isn’t that wonderful?!!
  3. You’ll force Frontend people to develop also the Backend part
  4. You’ll force Backend people to develop also the Frontend part
  5. You can download and setup your project in one step
  6. You can still work on each project separately
  7. You can run both Backend and Frontend in one command (check the repository for a very simple Foreman configuration)
  8. You can still deploy each project separately (you may be interested in this small piece of bash:
if [ `git diff — name-only HEAD~..HEAD backend | wc -l` -gt 0 ];

which will tell you if the last commit made any change in your Backend.

I want to do it now!

If you want to follow this approach and you have already two different git repository you can check this comment on StackOverflow to merge them into one repository. Remember also to do that in agreement with the rest of your team which will have to switch entirely to the new approach.

Conclusion

I wrote this article to confirm this as a correct approach when developing one or more applications strictly related to each other. I know about the downsides, like a bigger git history or the difficulties of having two Travis configurations very different, but I think the benefits are much more then the disadvantages.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.