I’m working at a medium size organization inside a large company with about 30 developers in it and we’re considering moving to a microfrontend implementation. We are debating between a using a monorepo or multi-repo strategy and I wanted some advice (and maybe some anecdotes) on people that have gone through this. Thanks!
I strongly prefer monorepo setups. We used to have a multi-repo setup but ended up transitioning to a monorepo and have been extremely happy with our decision.<p>Multi-repo setups induce a lot of overhead, especially if you don't already have people on your team who know how to manage them. Monorepo setups are just /easier/ on average.
To illustrate, here's a simple situation you might run into: you're attempting to upgrade two software components at the same time.
For a multi-repo: you open up PRs with the updates for each repo, great. Now you want to test that the two PRs work correctly together. So you might have a third repository with integration tests that can stand up both components with references to your other repositories via submodules. You create a branch on your integration testing repository and check out the appropriate branches of each submodule. You'll also need to keep these submodules updated whenever you update the corresponding PRs. If both updates need to be atomic then you'll need something to make sure both PRs are merged before any releases get cut. You'll have to start throwing some serious automation on top of all of this or it'll become too annoying to manage.
For a monorepo: you create one PR with changes to both components. All of your tests run within the monorepo.
I've experienced both, and I prefer the mono repo.<p>Our challenges with multiple repos mostly revolved around builds and orchestration. We had to apply all build/deploy changes to all repos, and that increased the chance of doing some small thing wrong. Finding what exactly is wrong with one repo that should be the same as all the others was like one of those "find the differences" pictures. Really annoying.<p>This is more microservices than multi repo related, but making sure all the different services are released in sync was hard and annoying and often caused issues. Eg a specific API was updated and released but the for a consumer had to be rolled back and the rolled back version wasn't compatible with the new API. So current version and roll back wasnt an option. Rolling back the API would require rolling back all consumers but crap, one of the consumers applied a big migration to our core database and rolling that bank would take forever. And so on.<p>Just tons of little edge cases that went wrong at the worst time because it was so hard to foresee all the issues.<p>Monorepo and monolith is so comfy. Want to share code? Move it up one or two directories and import from there. No issues with two bundled react versions in two builds. Easy to refer to code from other teams, never an issue that someone forgot to add you to that one repo almost no one uses but that you need to commit to during firefighting.<p>I'm not saying multi repos/micro services can't work, but it's hard - you need strong processes that prevent people from being lazy, you need monitoring and management well defined, you need extra tooling that's aware of the repo structure, you need a strong story around migrations, and so much more.<p>I currently work with a mono repo
monolith that over a thousand devs contribute to daily and it's Cindy comfy. It feels much easier to fix too many devs in one repo (primarily via strong compartmentalization) than to fix too many repos/services
I will probably get whipped for this, but what about submodules?<p>If I am working on a bigger project with multiple smaller projects I create a folder structure locally anyway!<p>I can commit them too and when pulling I can just choose to only pull the one submodule instead of all of them?<p>Working on them is essentially the same, you just need to update the main repo once in a while or run git pull independently.
You will not have the developer tooling and know-how to pull off a good monorepo workflow. Avoid it. I can assume this because, well, if you have to ask then the answer is a solid <i>no, don’t do it</i>.<p>Nothing is worse than half-baked monorepo solution.
Philosophically I think the monorepo is better. However it is my experience that most commonly available dev tooling assumes multi-repo setups and that ends up requiring you to write a lot more tooling and glue for CI/CD than you might want to be doing.<p>Monrepos can encourage a lot of good practices and can provide some pretty large benefits which is why many large engineering orgs gravitate to them. But most of those orgs have the capacity to absorb the tooling costs they bring as well.
Both approaches have their good and bad sides. There is, however, a way to combine the advantages of both ways, having a monorepo synchronized with multiple individual repositories by Git X-Modules(<a href="https://gitmodules.com" rel="nofollow">https://gitmodules.com</a>).<p>I am a part of the team behind it, so AMA about the tool :-)
><i>microfrontend implementation</i><p>What does this mean?<p>>* We are debating between a using a monorepo or multi-repo strategy*<p>Why? What's the debate like?
This is a communication problem, not a technology problem. Either could work or fail. Trade offs will have to be made.<p>Complexity doesn't go away, it's moved to another layer :)