Multi-language Monorepo

Question

We currently have a "front-end" git repository that is all of our JavaScript client apps, and a "back-end" git repository containing all back end APIs written in .NET Core. There is also a few other random repositories built on differing technologies. This is all managed via Azure DevOps, which I believe will let us trigger builds on particular paths.

front-end repo
-- applications
----app1
----app2
-- common-library

back-end repo
-- apis
----api1
----api2
--common-library

some .net-core-product repo

We were considering putting everything in a single mono-repo because it is easier for the developers to manage with git clients such as Visual Studio. I cannot find an example of a multi-language monorepo - is there an example on github? What are the pros/cons?

Solution

Monorepos have been getting a lot of attention in recent years since google popularized them. If you aren't on a similar scale as google it might not work out as well for you. I've been in a startup that moved to monorepos and we quickly found that:

• most tools are built with one repo leading to one artifact that gets deployed. You will have to rework all of those tools to handle the monorepo. There are tools that are designed for monorepos.
• a monorepo puts all of your eggs in one basket. If somebody steals a laptop would you rather them get half of your code or all of it? Keeping different things in their own repos reduces exposure.
• your CI for code validation is now much more complicated. You need to support multiple languages in your code conformance tests. Developers will get upset when you check backend stuff and they've only made frontend changes. Now you're stuck trying to figure out how to disable some CI checks, but make sure they're enabled when needed.

All of this adds up to a load of work for release engineers. Do you have people focused on release engineering with free time to tackle multiple complicated projects? Google can make this work because they have hordes of engineers and they can dedicate ten folks to this sort of thing for months until it is smooth enough to develop on top of. If you are not at the same scale as google you might not be able to follow their example. The folks that have succeeded with this tend to be big organizations. You may not have found an open source example because none exists.

These points are also noted in this article:

The frank reality is that, at scale, how well an organization does with code sharing, collaboration, tight coupling, etc. is a direct result of engineering culture and leadership, and has nothing to do with whether a monorepo or a polyrepo is used. The two solutions end up looking identical to the developer. In the face of this, why use a monorepo in the first place? Please don’t!

So focus on improving your engineering culture and don't get worried about not following the latest tech trends.

Comments

[Admin]

if your devs cannot handle multiple repos you need better tooling to automate the builds etc ... keeping distinct repos encourages better loose coupling which can get lost going to mono ... remember any project today is already pulling in dozens if not hundreds of different libraries often directly from their own repos so handling multi repo is never going away and going mono can be self limiting

[BPD]

Twitter is another company that uses a monorepo.

[AjaxLeung]

A proper workspace solution will have each project be its own repo, but the workspace can add or remove repos to the workspace so basically you get both the benefits of a polyrepo and monorepo. This is how Amazon built its internal Brazil workspace tool. You need to test how 2 modified repos would behave when shipped together? just add both to your workspace.