Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What are the pros / cons of using monorepos?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Ask HN: What are the pros / cons of using monorepos?

#91

Post by influx »

dastbe wrote: post #72
influx wrote: post #33

Twitter: Monorepo Facebook: Monorepo Google: Monorepo Amazon: Multirepo Of these companies, compare AWS and the number of services, new features and quick turn around time with their competitors, and get back to me.

What makes Amazon's multirepo setup "tick" isn't the multirepos themselves but the coordination mechanisms around it (version sets, brazil, and pipelines). whereas bazel/buck are open source and work ok enough to scale monorepos, i dont think there are the equivalent tools out there for multirepo and it shows in the comments for people with multirepo pain. EDIT: that being said, I do think multirepo is better, but on…

Agreed that Amazon build and deploy is vastly ahead of bazel/buck. That said, git just works so much faster on a smaller repo. There's significant overhead trying to use git or hg on a huge monorepo that really takes a toll on development.

Re: Ask HN: What are the pros / cons of using monorepos?

#92

Post by voxl »

gen220 wrote: post #46

I've worked in environments across the version-control gamut. The best-run places have had monorepos. But, for the life of me, I would not trust the companies that didn't have monorepos, to operate a monorepo. To go mono is to make an org-level engineering/cultural commitment, that you're going to invest in build tools, dependency graph management, third-party vendoring, trunk-driven development, and ci/cd infrastruc…

It's strange that you make this incorrect comparison to static and dynamic typing. As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken. That sounds like _dynamic_ typing to me.

Re: Ask HN: What are the pros / cons of using monorepos?

#93

Post by triceratops »

voxl wrote: post #92
gen220 wrote: post #46

I've worked in environments across the version-control gamut. The best-run places have had monorepos. But, for the life of me, I would not trust the companies that didn't have monorepos, to operate a monorepo. To go mono is to make an org-level engineering/cultural commitment, that you're going to invest in build tools, dependency graph management, third-party vendoring, trunk-driven development, and ci/cd infrastruc…

It's strange that you make this incorrect comparison to static and dynamic typing. As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken. That sounds like _dynamic_ typing to me.

> As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo?

In a monorepo if your change breaks someone else's code, you'll know immediately because you won't be able to check in the code with a breaking build. If you have the correct monorepo tooling set up it will help you figure out what you're breaking.

With multi-repos others will have to upgrade to your new version and then see that their code is breaking.

GP's analogy was imperfect because as you pointed out the company has to invest in the monorepo tooling. But it makes sense to me.

Re: Ask HN: What are the pros / cons of using monorepos?

#94

Post by triceratops »

Communitivity wrote: post #15

Mono-repos are either a shortcut to avoid release management and dependency management, or are a way to manage development at scales approximating Google's. First, for almost all companies copying non-selectively what Google does is harmful - you are not Google. Second, if you are a small team, your code only produces one binary that is shared across team boundaries, then you might be able to do with a monorepo. But…

> Mono-repos are either a shortcut to avoid release management and dependency management

In a small company, release and dependency management are pointless busy work. And in larger companies, you have enough labor to manage monorepo tooling.

> Using multiple repos, one per shared product (library, SDK, web site, documentation package) is harder to manage because you need to manage your dependencies much better and pull in the correct versions for the current product.

This is the pointless busy work I was alluding to. See also: the diamond dependency problem. Meanwhile the benefits are unclear.

Multi-repos makes sense for entirely disconnected projects or products, or for collaboration in the open-source world. Most companies aren't going to run into significant issues with scaling a monorepo and they'll save a ton of work.

Re: Ask HN: What are the pros / cons of using monorepos?

#95

Post by gen220 »

voxl wrote: post #92
gen220 wrote: post #46

I've worked in environments across the version-control gamut. The best-run places have had monorepos. But, for the life of me, I would not trust the companies that didn't have monorepos, to operate a monorepo. To go mono is to make an org-level engineering/cultural commitment, that you're going to invest in build tools, dependency graph management, third-party vendoring, trunk-driven development, and ci/cd infrastruc…

It's strange that you make this incorrect comparison to static and dynamic typing. As with static typing, an automated tool prevents you from doing something. It comes for free at the cost of you needing to satisfy the tool. Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken. That sounds like _dynamic_ typing to me.

> Where is this in a monorepo? You make it sound like the company itself must invest in assuring that the rules are not broken.

My argument, as made in the original comment, is that a monorepo is not a git repository. It is a git repository, a build tool / dependency graph manager, and a continuous integration system.

In the same way, a statically-typed project is not a collection of source files. It is a collection of source files, a linker, and a compiler.

The linker and compiler do not come "for free" any more than a build tool / ci system do, although they have been around for a very long time so you might consider them part of the background. In a well-structured monorepo, the build tool and ci system are as much in the background as `gcc` or `go build` might be.

Re: Ask HN: What are the pros / cons of using monorepos?

#97

Post by jzoch »

I find internal libraries are incredibly frustrating to manage in microservices. I spend more time changing the library, updating each service to the new version, getting PR approvals, and deploying then with a monorepo. Additionally, identifying that changes in my library dont break any of my clients are more difficult in distributed repos.

This is all with a fairly robust CI/CD pipeline so its not like i'm marred by inefficiencies elsewhere -its just an annoying process that makes me (and others) not want to write libraries.

edit: I should qualify that this is most annoying when you own the library and the services that consume the library. If the burden of the upgrade was left to my customers then the tradeoff might be different for me :)

Re: Ask HN: What are the pros / cons of using monorepos?

#98

Post by closeparen »

A monorepo is a transfer of convenience from people who make services to people who make libraries. A library author's change automatically runs the tests (pre land) and CI/CD pipelines (post land) of every dependent service, where previously it would have taken months of wrangling to distribute a library release this widely. But service author laptops are now struggling under the weight of every line of code at the company. Git operations take long enough for you to lose interest and tab over to HN. After a git pull, many of your dependencies have changed which can break things (at worst) or just invalidate a lot of cached compilation and make the next build slow (always). You need the build system to generate a "mask" for your IDE so that code intelligence doesn't try to index the whole thing in memory, etc. Buck and Bazel are less familiar and less ergonomic than languages' native or customary toolchains. You need further tools (or a lot of manual effort) to keep the monorepo build system's own configuration files in sync.

Re: Ask HN: What are the pros / cons of using monorepos?

#99

Post by ali92hm »

jrockway wrote: post #54
dehrmann wrote: post #40

Earlier quoted context omitted.

In mono/mulirepo debates, I frame this as multirepos make hard, scary things hard. Monorepos make it easy to introduce changes that break APIs at deploy time, but are hidden by the atomic commit actually being OK.

I think API versioning is orthogonal to how you organize your code. If you have multiple repos, then you still have that "atomic commit" where you update the version of the client library and adjust the code to handle the new semantics. It then breaks when you deploy it to production because the server code isn't deployed yet (or vice versa). Basically, if you make RPCs, breaking up your repositories or combining you…

> Basically, if you make RPCs, breaking up your repositories or combining your repositories doesn't eliminate this problem. I kinda agree with this.

But as someone who has always worked in a microservice environment kept by different git repos I don't understand the benefits of a mono repo. I can see the benefits of a mono repo in a massive code base that produces a binary at the end (i.e. windows). But could you elaborate more on the benefits of a mono repo in the case of many small microservices?

Post reply on HN