What are the benefits and downsides of choosing one approach over another.
From the perspective of a small team.
Ask HN: Mono Repo vs. Multi Repo?
1–10 of 14 posts
Re: Ask HN: Mono Repo vs. Multi Repo?
#2Mono all the way.
Re: Ask HN: Mono Repo vs. Multi Repo?
#3Mono all the way.
Any particular reason???
I have read some blogs. But wanted to know from HN, what developers prefer.
Re: Ask HN: Mono Repo vs. Multi Repo?
#4I 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.
Re: Ask HN: Mono Repo vs. Multi Repo?
#5Mono 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.
Re: Ask HN: Mono Repo vs. Multi Repo?
#6Re: Ask HN: Mono Repo vs. Multi Repo?
#7Earlier quoted context omitted.
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.
Re: Ask HN: Mono Repo vs. Multi Repo?
#8Mono 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 packag…
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?
Re: Ask HN: Mono Repo vs. Multi Repo?
#9I 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 multi…
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.
Re: Ask HN: Mono Repo vs. Multi Repo?
#10I 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 multi…
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.