[HN Gopher] Monorepos: Please Don't (2019)
___________________________________________________________________
Monorepos: Please Don't (2019)
Author : jrpelkonen
Score : 14 points
Date : 2024-04-28 17:20 UTC (5 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| gladwindos wrote:
| I've heard about how huge companies like google are using a giant
| monorepo, and I honestly don't understand how that could work.
| But I guess it does...
| inhumantsar wrote:
| with lots of controls and custom tooling
| verdverm wrote:
| Facebook open sourced theirs
|
| https://github.com/facebook/sapling
| shawabawa3 wrote:
| Having seen a large org attempt a poly -> mono repo conversion
| project (which took almost 2 years and failed and was in the
| process of being rolled back when I left) I agree with everything
| in this article
|
| Once an org becomes large enough you need lots of custom tooling
| to make working across a huge codebase smoother, and that tooling
| is similar for mono and poly repos, but you need an additional
| metric ton of tooling to make monorepos work
|
| And please pray you didn't decide to go with bazel for builds
|
| My least favourite monorepo experience: I want to update my
| dependency for my tiny service for a security patch -> Oh, 400
| other services depend on it and dozens of tests break when I try
| to update it -> this isn't worth my time I'll do something else
| instead
|
| We were promised a world where every dependency was kept up to
| date by necessity but ended up in a world where all dependencies
| atrophied due to the increased difficulty to update them
| jpc0 wrote:
| > I want to update my dependency for my tiny service for a
| security patch
|
| If the API changed it's not a security patch... Why would a
| change that only fixes a security bug cause tests to fail?
|
| Sounds like this is more a matter of needing to cherry-pick
| temporarily and then actually pushing for the codebase to
| update, probably by the security team.
|
| Sometimes you need to work with other people, that might
| necessitate doing "ugly" things to get the job done.
| thornygreb wrote:
| Yes, but very often you are trucking along just fine with
| some version of a dependency and then all of a sudden it gets
| a CVE and the fix has only been applied to the next major
| version and not backported because the version you are on is
| no longer supported. And now you are in dependency update
| cascading hell.
| tdb7893 wrote:
| Having worked at a place with a monorepo it was one of the
| things I actually really liked about working there. It took a
| lot more tooling but I found it to be much better than a multi-
| repo would have been, even with a similar amount of tooling. I
| didn't have to be checking different projects out all the time
| and changes across projects weren't too bad (large scales ones
| still took a lot of managing but not as much as changes across
| a multi-repo).
|
| I was always hoping that one of the big cloud providers would
| offer a monorepo and invest a lot in making tooling for it to
| actually be usable.
| karmakaze wrote:
| This actually explains why Google is so keen to retire products
| that don't necessarily cost much to run, but don't turn a
| profit yet.
| Hackbraten wrote:
| TFA assumes several things which may or may not hold for a
| particular company or team.
|
| For example, the Linux kernel works with its tens of millions of
| lines just fine, even though ownership is heavily distributed
| among many subsystem maintainers. Checking out a branch or
| pulling in changes rarely takes more than a few seconds.
|
| On the other hand, some organizations abuse their VCS, using it
| as a repository for large immutable files such as build
| artifacts, software packages or similar non-source archives. Orgs
| who let this happen are of course going to have a hard time. But
| that's hardly the monorepo's fault.
| veidr wrote:
| This article sucks. Does your company have tens of thousands of
| employees? If so, hopefully you have some engineers working on
| your tooling. If not, you don't have the problems described here,
| and you will also happily get all the "theoretical benefits" that
| this guy apparently didn't experience.
|
| Moving to monorepo is often a win; also the name sucks, we have a
| a few "monorepos" at work, and I think it's the sweet spot. Rust
| and C firmware doesn't need to live with TypeScript frontend
| apps, but it's pretty wasteful to have apps of the same ecosystem
| unable to share any and all dependencies and utility code
| trivially.
|
| (Where "trivially" means literally one line of code
| import { bleargh } from 'hoge';
|
| and not one single step more.)
| worksonmine wrote:
| You can npm install repositories, no need to merge frontend and
| backend just to share code. Break out what can be shared into
| utilities and you can share it in completely unrelated projects
| as well.
|
| I get monorepos for SSR and the likes but why build and deploy
| an entire container to push a line of CSS?
| verdverm wrote:
| Polyrepo ends up with a mess of version management and flood
| of PRs to roll out minor changes
|
| Imagine adding a field to a table that must be reflected in
| the front end and some other micro service consumers.
| Coordination can be painful.
|
| Each system has its pros and cons, you're going to need
| tooling either way. I've moved to mono or mega repo as the
| default and break out smaller pieces into dedicated repo as
| needed
| gorjusborg wrote:
| I get the feeling what you call a monorepo is microscopic
| compared to what the article is discussing.
|
| Your monorepo sometimes approach _is the polyrepo
| approach_.
| worksonmine wrote:
| You're going to have to edit the code in 2 places either
| way. With a sane deployment strategy the backend would have
| the extra field, then you can deploy the frontend to render
| said change. Or sometimes the table is dynamic and doesn't
| even need changes on the frontend.
|
| To me the ability to push changes independent of other
| pieces far outweighs the extra git commit and push. I've
| never had the need for any other tooling than a container
| to run in, git to manage code, and CI/CD for deploys. If
| there's a need for special tooling to manage the projects
| there's to much complexity for my taste and I remove the
| complexity instead.
| javcasas wrote:
| At work, I pushed for a monorepo. We deploy everything as
| docker containers, both the backend, the frontend and the
| services. Each service imports and compiles what it needs,
| nothing more.
|
| We could look to deploy CSS in a different way to optimize
| the use case for updating a single CSS line, and deoptimize
| everything else.
| hfcbgfccc wrote:
| I don't understand why deployment approach is related to mono
| vs multi repo?
| worksonmine wrote:
| Read the comment I'm replying to and you'll see the
| context, a single deploy for changes on backend and
| frontend is mentioned as a benefit. I'm suggesting
| deploying in order so a frontend doesn't expect a field
| that doesn't yet exist on the backend.
| verdverm wrote:
| I've been saying "megarepo" because I tend to split things into
| a few large groups and then have dedicated repos for places it
| makes sense
| pptr wrote:
| How do you share config files, protobuf schema, etc. between
| frontend and backend if you have different repos for each?
|
| I have only worked in large codebases with monorepo, so I'm
| curious.
| abswest wrote:
| You build a package and publish it to a private registry, so
| builds can reference specific versions of dependencies from
| other repos.
| dijit wrote:
| We use a jenkins job that watches the "source of truth" repo,
| which in our case is the backend.
|
| Jenkins creates all the protobuf definitions and pushes them
| to their dependent repos.
|
| A better way would be with a package repository for them, and
| having it versioned; and running multiple versions of the
| backend.
| liampulles wrote:
| I think of org-wide monorepos the same way I think of zealous
| microservice use, or microfrontends, or platform engineering,
| etc. It is a "shiny thing" that FAANGs use, which get a
| disproportionate amount of tech evangelist coverage, and then
| transition into becoming the perceived "best-practice" by bored
| devs (myself included) to then create some tech-debt work.
|
| The reality is that these are somewhat niche usecases for very
| high scale orgs and/or very high-scale developer workforces which
| can afford to reinvent the wheel. The way the vast majority of
| companies should go about developing their systems is not new at
| all, its just to pragmatically apply tried and tested
| technologies, and transition to new shiny things where there is a
| demonstrable need.
|
| Worth saying that I'm definitely a fan of team-scoped monorepos
| though. Being able to automate building and testing across all my
| apps, update dependencies across all apps, and deploy with a
| single merge/pull request is great.
| quectophoton wrote:
| I get what the article is saying. But if `ls -d ../*/.git/`
| prints the names of all the company's repos, and the same happens
| in a few coworker's computers, I start to question things.
| erik_seaberg wrote:
| Keeping prod stable is more important than alpha testing every
| team's latest commit, but monorepos tend not to accommodate
| staying on known-good versions of your dependencies and opting
| into updates when ready.
___________________________________________________________________
(page generated 2024-04-28 23:02 UTC)