[HN Gopher] Just Use a Monorepo
___________________________________________________________________
Just Use a Monorepo
Author : jmduke
Score : 26 points
Date : 2023-01-12 20:20 UTC (2 hours ago)
(HTM) web link (buttondown.email)
(TXT) w3m dump (buttondown.email)
| throwaway_au_1 wrote:
| I would like for any article insisting I adopt any practice to
| put a little more effort into doing so. This seems to amount to
| "it's good", "I should have done it sooner", "it's not so bad,
| trust me", and "smart people like it, too". Could have been a
| tweet.
| yodsanklai wrote:
| Agree, not a good article. Hopefully it'll trigger interesting
| discussions.
| arrakeen wrote:
| this is the first i've heard of "microrepositories" but it
| appears like the author may have just been overzealous with
| partitioning their repositories and has now settled on what most
| of us would just call a "repo".
| yodsanklai wrote:
| My understanding is that Meta/Google had to rewrite tons of stuff
| (distributed file systems, CVS, search tools, build tools...) and
| need many teams to maintain all these systems, and sometime their
| developer experience is inferior to what you get with off-the-
| shelf OSS. I'm not super familiar with this topic as I don't work
| with systems of that scale, but I'm wondering was it worth it or
| necessary? what would be the alternative?
| hahaxdxd123 wrote:
| > sometime their developer experience is inferior to what you
| get with off-the-shelf OSS.
|
| The internal version control system that I use (Fig, which is
| apparently based off Mercurial) is so good I've basically never
| had to think while using it. I can't really say the same about
| git.
|
| CodeSearch is also, AFAIK, a lot better than what you would get
| OSS.
|
| I think the productivity gains across 100K engineers is
| definitely worth it.
| 015a wrote:
| IMO the biggest drawback to a monolith, maybe beyond those
| listed, is losing the 1-1 mapping of changes to CI to releases.
| If you know "this thing is broken", the commit log is a fantastic
| resource to figure out what changed which may have broke it. You
| submit a PR, and CI has to run; getting most CI platforms cleanly
| configured to, say, "only run the user-service tests if only the
| user-service changes" isn't straightforward. I understand there
| are some tools (Bazel?) which can do it, but the vast, vast
| majority of systems won't near-out-of-the-box, and will require
| messy pipelines and shell scripts to get rolling.
|
| There's also challenges with local dev tooling. Many VSCode
| language extensions, for example, won't operate at their best if
| the "language signaler" file (e.g. package.json for JS) isn't in
| the root of the repo; from just refusing to function, to
| intellisensing code in another project into this one, all manner
| of oddities.
|
| Meanwhile; I don't think the purported advantages are all that
| interesting. Being able to write the blog post and make the
| change in the same PR? I've never been in a role where we'd
| actually want that; we want the change running silently in prod,
| publish the blog post, flip a feature flag or A/B test
| proportions. Even an argument like "you can add schemas and the
| API changes in one go"; you can do that without a "monorepo",
| just co-locate your schemas with the API itself, this isn't
| controversial or weird, this is how everywhere I've worked
| operates.
|
| None of that is to even approach the scale challenges that come
| with monorepos at even reasonable sizes; which you can hit pretty
| quickly if you're, say, vendoring dependencies. Trying to debug
| something while the Github or Bitbucket UI is falling over
| because the repo is too large, or the file list is too long,
| isn't fun.
|
| I'm not going to assert this is a hill I would die on, but I'm
| pretty staunchly in the "one service, for one deployment
| artifact, for one CI pipeline, for one repo" camp.
| mr90210 wrote:
| Just use what works well for you and your team, how about that?
| xiphias2 wrote:
| ''I am here to tell you: if you are running a software business
| and you aren't at, like, Google-tier scale, just throw it all in
| a monorepo.''
|
| Google _is_ a monorepo
| BoorishBears wrote:
| It really paints a picture of the authors credentials to be
| making this declaration.
|
| All signs for the rest of the world point to the opposite
| conclusion: unless you're Google-scale, you don't have Google
| level resources. Google has more engineers working on developer
| experience than most companies will ever have period.
|
| And monorepos work best when workflows are carefully thought
| out with clever application specific tooling.
|
| -
|
| I think the author is probably working on a 1-10 developer
| project (and I'm leaning towards 1) and has confused the
| convenience with having things in reach when the entire system
| fits in your mind with the general benefits of a monorepo.
|
| I honestly wonder if they read any of the letters they linked
| too...
| harryvederci wrote:
| I use a megarepo, if that's a thing.
|
| One repo with multiple unrelated apps, plus a "shared" directory.
|
| I could put the shared dir in a package, but so far I don't
| really see the need.
___________________________________________________________________
(page generated 2023-01-12 23:00 UTC)