Ask HN: Mono Repo vs. Multi Repo?
What are the benefits and downsides of choosing one approach over another.
From the perspective of a small team. I prefer monorepo for tightly coupled systems (like a game server and client), and multi repo for multiple, loosely coupled systems (like a web API and mobile app). The main problem with monorepos is that without the resources to build proper tooling, you end up with useless commit logs and losing track of context while working, but once you're on a larger team the advantages may be better. However, if you have multiple teams working on different, a multi repo might be better; for example, if you have a team for your API and a different team for your website, then multiple repos might be better depending on how coupled they are. Either way, it doesn't really matter that much. In the end, it's mostly just a personal preference. I read somewhere that with larger teams, maintaining mono repo becomes harder because of merge conflicts. We are a small team and the codebase would not be that big. If everything is tightly coupled (which it sounds like from your other comments), then go ahead with a monorepo. Should be fine. Thanks for the suggestion. Mono unless you have a great reason not to. Frontend and backend parts of the app can be a good reason, so you don't have to clutter either with stuff related to builds etc.. Going multi first is just too annoying to manage and doesn't make much sense. Also, it's more repos you have to get running on your device, and more room for divergence. It gets even worse when small companies insist on creating their own packages... Also, I usually have a repo that is for deployment-focused stuff, like kubernetes configs. These are good reasons. I think maybe a "scripts" or "scratch file" or a mix of the two can also be its own repo, for stuff that doesn't really belong anywhere specific and isn't getting called by other code. Thanks. I now think that Mono would be a better choice. As we only do Integration and azure related stuff. So most of the code will be dependent on each other and reusable. Is it also better if we have to use some open source dependency at multiple places? > Is it also better if we have to use some open source dependency at multiple places? I'm not sure what you mean! Multi. Always. The question with monorepos is not if they will become a nightmare. It is when they will become a nightmare. Making a multirepo feel like a single workspace is trivial.
Making a part of a monorepo feel like a repo from a multi repo is impossible. Mono all the way. Any particular reason???
I have read some blogs. But wanted to know from HN, what developers prefer. Can I ask your motivations? We are going to do some Integration work, that may include Azure functions, servicebus, micro services and other stuff.
We are creating some POCs for that and had a discussion about what approach to use. I have worked with multi repos and not so sure if Mono repo would be better. As most of the components that we will be creating will be interdependent. sounds similar to our setup. my advice is be thoughtful how you are creating new micro services, be thoughtful with servicebus (as the SLA on the cheap tier is not great), and be thoughtful with azure functions! Can get out of hand - both in cost and productivity issues - quickly. We have a guy on our team who loves the shiny new thing, but lots of times you can get it working in a much easier, more understandable way. For azure functions, a separate repo may make sense. I would probably do that, but I also suggest not putting much logic at all in the azure functions. For example, this: - When the function is executed, drop a document here - ... write this db record - ... execute some job somewhere ... - ... call an API ... Is a good use of azure functions. Keep it "functional!" Bad uses are "systems" implemented in Azure functions. As soon as you feel like you need to use or even MIGHT need to use code in your main codebase, please, don't use azure functions! :)