Actually one of the most reflected opinions regarding this topic I've seen so far. [Imho] Both approaches can become doomed, and both can lead to great success-stories. In my experience the biggest benefit of small independent repos is their atonomy, their biggest downside is their tendency to create dependency-hell (or it's weaker cousin, orphaned projects, which are still in use). On the other hand the biggest strength of monorepos is their ability to show the whole picture, unfortunately they tend to rely on heavy tooling as their biggest downside. [/imho] Unfortunately I see a trend in the last 5 years, especially in the JS/TS community, to build tooling which only serves a their language and don't support propper support for other tool-chains. This is really bad for monorepos, since one of the key-ideas of such a setup is to not constrain you too much on the language. (Buck/Bazel/Gradle/Nx [mostly language independent] vs. TurboRepo/Lerna [heavily relying on one language]). Another pain-point can be to maintain languages which (by default) rely on a specific structure of repositories or directories, like golang...
what's your thoughts on having a package as a *git submodule* that exists as a stand-alone repo and also within your monorepo for 2 or more teams that need to work on the same project?
@7:35 "make sure that no more than one team is using a specific monorepo", is this an error? Did you mean folder/project in the specific monorepo? And what is with the wording "specific monorepo" does it imply a multitude of monerepos, isn't that the multirepo scenario that monrepos are supposed to solve? And if you really meant one team at the time working on a monorepo, what are the ways to avoid this sequential bottle-neck? Reminds me of the version control systems of old that used to explicitly lock individual files by individual developers (horror!)
How can I configure the mono repository to use same package in each and every project ? Let’s say we have our UI and API projects in mono repo, both written in JS. Now how can we make both to use same package version ? Because each of them have it’s own package.json to manage its own dependencies, right ?
My main issue with Monorepos is the required config. If you can't understand the config from a quick-glance, get rid of it! Because when the author leaves the team, you're screwed. Web development is 50% config hacking these days
i just studied nx and turborepo, migrating it require me to study specific configuration for each, and doesnt work at first try, definetly learning curve
I used Next with Nx and it wasn't that bad, to be honest. Worked well with Vercel, as well. Also, people shouldn't own projects, applications, or features. These should be documented so they can be shared and picked up by other Devs in the case that someone leaves, it can be easily picked up.
in our case we build software for clients so the repos need to be separate, also licencing comes into these decisions some clients own the code others licence it
Thanks for the comment, buy could you please explain why exactly it had to be separated? Because I would think that you can give them access to the whole repo and they’d be happier, than if they have to deal with multiple repos
thanks man you explain very well, but I have a small question what if I have to deploy multiple services with mono repo using CICD, should I wait till a service is done and then execute the next one or is there a way to deploy them at same time?
That's a really good question. It depends on your requirements: do your services depend on each other for ex. is there a specific setup that has to be finished or maybe some library is being used from a parent service? If there is no dependency then you can deploy them in parallel, otherwise you have to configure your pipelines to do it sequentially.
I've been wondering about that too. I think you should be able to set up your CI/CD jobs in such a way that allows for parallel execution. If there are any dependencies, you can set up a job that runs only when the dependency is done and ready. Idk but this is what makes sense to me
Its good advice to avoid multiple teams working on a single codebase whether its a monorepo or not. It doesn’t mean that members of other teams can’t contribute, but there should be a single owner of that repo to help prevent disruptive changes to the code. I would consider this a facet of Conway’s Law (the creator touched on this but didn’t name it): development is most efficient when code is structured similarly to the organization’s structure and vice versa. Having a single team own a single repo is more efficient than a single team owning multiple repos or multiple teams owning a single repo. Its not a hard and fast rule, but its been mostly the case in my experience. Anyway, i’ve been using monorepos for years, and I’ve found that its best when only one team works on it. When we get too big we just break the monorepo up as needed (actually in the process of this now after about 14 months on a project). So its just a guideline, but i do agree with the creator’s advice on this one.
Isn't a mono repo only an advantage if the services only depend on eachother at compile time? One can have multiple services, written in different languages that have nothing to do with eachother at compile time. It is the interface definition that defines their dependency. And the risk of breaking that only occurs at run time (in an integration test environment, before it is deployed to production). Storing each service in it's own repo works perfectly fine than.
Isn't a monorepo for team a separate issue that team can decide without other teams that make direct updates to included submodules even needing to know about it? In other words, a monorepo is an extra aggregating repo that simply allows you to deal with multiple independent repos together. So it doesn't destroy anything by making it available. Am I missing something?
No more monorepo! Total chaos..At the time of making your video Kubernetes and Google were already transisioning to polyrepos. I've never seen a monorepo that works well with gitflow. A repo that just respects a normal gitflow. Sooo yeah those companies started back in the days.
Absolutely no value to this video. A lot of rambling explaining what monorepos are and at the end a neutral diplomatic opinion. No technical explanations, no breakdown of pros and cons of specific monorepos as opposed to others. I could make this video with 12 mintues of using a Monorepo, not 12 months.
Polyrepos are also helpful when you want your code (business) logic to be packed differently for deloyment over to varied hostings over different geographies, as separating the build in other repos works well when working with multiple teams, in a large organization. I have seen people trying to forcefully fit cases in monorepos which is not a good practice. It creates overcomplications and takes things away from the 'Single Responsibility' based thought processes. Just because Google or some other big org does it, shouldn't be the reason to force monorepos everywhere.
part of the gig is finding ergonomic ways to do things...generally what I see is that yes people sometimes "Force" things, but that was not the only option.
Great Job @sofwaredeveloperDaiaries. please i will like to connect with you regarding this topic of mono repo, if you do not mind please.. i have a project there, which i would like to understand somethings
Thanks. Please keep posting more such content.
Will do, my friend! Appreciate the Super Thanks! 😊
Actually one of the most reflected opinions regarding this topic I've seen so far.
[Imho] Both approaches can become doomed, and both can lead to great success-stories. In my experience the biggest benefit of small independent repos is their atonomy, their biggest downside is their tendency to create dependency-hell (or it's weaker cousin, orphaned projects, which are still in use). On the other hand the biggest strength of monorepos is their ability to show the whole picture, unfortunately they tend to rely on heavy tooling as their biggest downside. [/imho]
Unfortunately I see a trend in the last 5 years, especially in the JS/TS community, to build tooling which only serves a their language and don't support propper support for other tool-chains. This is really bad for monorepos, since one of the key-ideas of such a setup is to not constrain you too much on the language. (Buck/Bazel/Gradle/Nx [mostly language independent] vs. TurboRepo/Lerna [heavily relying on one language]). Another pain-point can be to maintain languages which (by default) rely on a specific structure of repositories or directories, like golang...
what's your thoughts on having a package as a *git submodule* that exists as a stand-alone repo and also within your monorepo for 2 or more teams that need to work on the same project?
hey - cool vide, thx! I like the design of the diagrams - what tool you are using on it? :)
It's just Canva :)
@7:35 "make sure that no more than one team is using a specific monorepo", is this an error? Did you mean folder/project in the specific monorepo? And what is with the wording "specific monorepo" does it imply a multitude of monerepos, isn't that the multirepo scenario that monrepos are supposed to solve? And if you really meant one team at the time working on a monorepo, what are the ways to avoid this sequential bottle-neck? Reminds me of the version control systems of old that used to explicitly lock individual files by individual developers (horror!)
Why only 1 team on a monorepo. I would assume we just resolve the merge conflicts with the clashing team? What do you think?
How can I configure the mono repository to use same package in each and every project ? Let’s say we have our UI and API projects in mono repo, both written in JS. Now how can we make both to use same package version ? Because each of them have it’s own package.json to manage its own dependencies, right ?
You want to search for workspaces. npm and all the other major package managers have a way to do this.
My main issue with Monorepos is the required config. If you can't understand the config from a quick-glance, get rid of it! Because when the author leaves the team, you're screwed. Web development is 50% config hacking these days
Good point
i just studied nx and turborepo, migrating it require me to study specific configuration for each, and doesnt work at first try, definetly learning curve
I used Next with Nx and it wasn't that bad, to be honest. Worked well with Vercel, as well.
Also, people shouldn't own projects, applications, or features. These should be documented so they can be shared and picked up by other Devs in the case that someone leaves, it can be easily picked up.
@@incarnateTheGreat Agree 100% with that last statement.
in our case we build software for clients so the repos need to be separate, also licencing comes into these decisions some clients own the code others licence it
Thanks for the comment, buy could you please explain why exactly it had to be separated? Because I would think that you can give them access to the whole repo and they’d be happier, than if they have to deal with multiple repos
Once a while the TH-cam algorithm recommends a great channel. Now is such a time.
Nice to meet you - keep posting great content
Nice to meet you too! Thanks for the kind words 😊
thanks man you explain very well, but I have a small question what if I have to deploy multiple services with mono repo using CICD, should I wait till a service is done and then execute the next one or is there a way to deploy them at same time?
That's a really good question. It depends on your requirements: do your services depend on each other for ex. is there a specific setup that has to be finished or maybe some library is being used from a parent service? If there is no dependency then you can deploy them in parallel, otherwise you have to configure your pipelines to do it sequentially.
I've been wondering about that too. I think you should be able to set up your CI/CD jobs in such a way that allows for parallel execution. If there are any dependencies, you can set up a job that runs only when the dependency is done and ready. Idk but this is what makes sense to me
no more than one team use monorepo, what??? Super confused. Are you suggesting multi-repo instead of MONOrepo? How can a company only has one team???
I’m at a start up, we’re just 5 devs i.e. a single team
@@gnrsn9714Sure, but limiting a monorepo to one team as a rule contradicts one of the main points of monorepos.
Its good advice to avoid multiple teams working on a single codebase whether its a monorepo or not. It doesn’t mean that members of other teams can’t contribute, but there should be a single owner of that repo to help prevent disruptive changes to the code.
I would consider this a facet of Conway’s Law (the creator touched on this but didn’t name it): development is most efficient when code is structured similarly to the organization’s structure and vice versa. Having a single team own a single repo is more efficient than a single team owning multiple repos or multiple teams owning a single repo. Its not a hard and fast rule, but its been mostly the case in my experience.
Anyway, i’ve been using monorepos for years, and I’ve found that its best when only one team works on it. When we get too big we just break the monorepo up as needed (actually in the process of this now after about 14 months on a project). So its just a guideline, but i do agree with the creator’s advice on this one.
Isn't a mono repo only an advantage if the services only depend on eachother at compile time? One can have multiple services, written in different languages that have nothing to do with eachother at compile time. It is the interface definition that defines their dependency. And the risk of breaking that only occurs at run time (in an integration test environment, before it is deployed to production). Storing each service in it's own repo works perfectly fine than.
Isn't a monorepo for team a separate issue that team can decide without other teams that make direct updates to included submodules even needing to know about it? In other words, a monorepo is an extra aggregating repo that simply allows you to deal with multiple independent repos together. So it doesn't destroy anything by making it available. Am I missing something?
Not really
i only just figured out how stupid i was all those years to maintain multiple private repositories for my hobby projects.
No more monorepo! Total chaos..At the time of making your video Kubernetes and Google were already transisioning to polyrepos. I've never seen a monorepo that works well with gitflow. A repo that just respects a normal gitflow. Sooo yeah those companies started back in the days.
Absolutely no value to this video. A lot of rambling explaining what monorepos are and at the end a neutral diplomatic opinion. No technical explanations, no breakdown of pros and cons of specific monorepos as opposed to others. I could make this video with 12 mintues of using a Monorepo, not 12 months.
Thanks for the feedback. You’re free to make your own video and I’d gladly check it out to learn from it :)
It's just that I've watched Fireship's video where he's talking about Nx and Turborepo so I had high expectations for this one.
Polyrepos are also helpful when you want your code (business) logic to be packed differently for deloyment over to varied hostings over different geographies, as separating the build in other repos works well when working with multiple teams, in a large organization. I have seen people trying to forcefully fit cases in monorepos which is not a good practice. It creates overcomplications and takes things away from the 'Single Responsibility' based thought processes. Just because Google or some other big org does it, shouldn't be the reason to force monorepos everywhere.
part of the gig is finding ergonomic ways to do things...generally what I see is that yes people sometimes "Force" things, but that was not the only option.
we have about 250 repos
Oopw
The Linked link you've used in your video description it doesn't work.
Great Job @sofwaredeveloperDaiaries. please i will like to connect with you regarding this topic of mono repo, if you do not mind please.. i have a project there, which i would like to understand somethings