4 ms·

Let's face it: monorepos are just huge monoliths. If you want modular software, you WILL have to pay the price of fragmentation. Someone needs to think about t

Let's face it: monorepos are just huge monoliths. If you want modular software, you WILL have to pay the price of fragmentation. Someone needs to think about the boundaries between different parts of a system. If those boundaries are defined by functions, classes, packages or services, it doesn't matter that much. Yes, it is always a pain. Shipping the entire forest of modules in a single repo seems like a good compromise. It stops being a good compromise when you start creating a complicated network of soft dependencies between those modules. And when you have everything in a single repository, it's hard NOT to do that. By the way, there's nothing wrong with monoliths. They're just better if you design them as such. There's nothing wrong with microservices as well. It shouldn't be a surprise though that neither of them are actually silver bullets. I understand why these solutions were created. I see it as an ephemeral thing. Once someone figures out the tooling and practices to automate all of that painful management locally, developers will always prefer that. Then when it's fast and easy, we'll break it once again (like we did with classes, packages, containers, etc).

ithkuil 4y ago
Monorepos and monoliths are orthogonal Monorepos are a tooling nightmare. Monorepos are a bandwidth black hole. Monorepos make some things possible that are just not possible or very very hard when you have multiple independent repos that are built and tested independently. Namely, a) they allow you to test the effects of a change on all the components that depend on you, before you merge your change. This reduces the noise caused by regressions (API or behaviour) introduced in one component that is depended on by many consumers. b) they are a practical way to ensure that all components have up to date internal dependencies: by placing the burden of API and behaviour breakage to the author of the change, you don't end up having hundreds of teams each struggling to keep up with dependencies that keep breaking their builds when you update them and consequently hating the teams that release those changes. None of these things is a big deal unless you're a huge company with hundreds of teams. I think in theory there could be some tooling and workflow that could provide all or moat of the benefits of monorepos, without the downsides. Until then, monorepos are likely going to be a bad choice for small companies.
- CrimsonRain 4y ago
  Can you explain how a monorepo for microservices is a tooling nightmare and bandwidth sink? In my experience, a monorepo significantly makes things easier and saves time everyday for all developers involved when compared with multi repo.
  - rtpg 4y ago
    The biggest issue is that every CI provider speaks with "repo=project" language, so your way forward with monorepos is using stuff like Bazel. Bazel is extremely cool! But you end up with, like, a handful of people on the team who can write Bazel and eveyone else cargo culting their way through it. There are a lot of JS "monorepo management" tools but they all seem concerned about the release phase for a lot of libraries that really should just be one library instead of 300 npm packages or whatever.
    - CrimsonRain 4y ago
      Thank you. > repo=project This has gotten better lately. At least, good enough for small-medium scale projects.
    - dilyevsky 4y ago
      > Bazel is extremely cool! But you end up with, like, a handful of people on the team who can write Bazel and eveyone else cargo culting their way through it. It's not that difficult and docs are outstanding. It can and it will be worse with your own Bash-isms that likely won't have any docs at all.
      - rtpg 4y ago
        I think Bazel is doing a lot of good stuff... but I think it suffers a bit from the same thing as Angular, where it makes a lot of its own terminology. There is another aspect where if you are using a language like Python or JS then you have to kind of swim upstream to get an existing project onto Bazel. Far from impossible but if you just look at the default Bazel stuff without pulling in third-party libs it's pretty tedious to get a project with a good amount of dependencies working.
allset_ 4y ago
> you start creating a complicated network of soft dependencies between those modules. And when you have everything in a single repository, it's hard NOT to do that. That is what the visibility [1] in Bazel solves. You can't import other people's code unless they say you can by making their code visible to yours. [1] https://bazel.build/concepts/visibility https://bazel.build/concepts/visibility

ithkuil 4y ago

Monorepos and monoliths are orthogonal Monorepos are a tooling nightmare. Monorepos are a bandwidth black hole. Monorepos make some things possible that are just not possible or very very hard when you have multiple independent repos that are built and tested independently. Namely, a) they allow you to test the effects of a change on all the components that depend on you, before you merge your change. This reduces the noise caused by regressions (API or behaviour) introduced in one component that is depended on by many consumers. b) they are a practical way to ensure that all components have up to date internal dependencies: by placing the burden of API and behaviour breakage to the author of the change, you don't end up having hundreds of teams each struggling to keep up with dependencies that keep breaking their builds when you update them and consequently hating the teams that release those changes. None of these things is a big deal unless you're a huge company with hundreds of teams. I think in theory there could be some tooling and workflow that could provide all or moat of the benefits of monorepos, without the downsides. Until then, monorepos are likely going to be a bad choice for small companies.

CrimsonRain 4y ago
Can you explain how a monorepo for microservices is a tooling nightmare and bandwidth sink? In my experience, a monorepo significantly makes things easier and saves time everyday for all developers involved when compared with multi repo.
- rtpg 4y ago
  The biggest issue is that every CI provider speaks with "repo=project" language, so your way forward with monorepos is using stuff like Bazel. Bazel is extremely cool! But you end up with, like, a handful of people on the team who can write Bazel and eveyone else cargo culting their way through it. There are a lot of JS "monorepo management" tools but they all seem concerned about the release phase for a lot of libraries that really should just be one library instead of 300 npm packages or whatever.
  - CrimsonRain 4y ago
    Thank you. > repo=project This has gotten better lately. At least, good enough for small-medium scale projects.
  - dilyevsky 4y ago
    > Bazel is extremely cool! But you end up with, like, a handful of people on the team who can write Bazel and eveyone else cargo culting their way through it. It's not that difficult and docs are outstanding. It can and it will be worse with your own Bash-isms that likely won't have any docs at all.
    - rtpg 4y ago
      I think Bazel is doing a lot of good stuff... but I think it suffers a bit from the same thing as Angular, where it makes a lot of its own terminology. There is another aspect where if you are using a language like Python or JS then you have to kind of swim upstream to get an existing project onto Bazel. Far from impossible but if you just look at the default Bazel stuff without pulling in third-party libs it's pretty tedious to get a project with a good amount of dependencies working.

allset_ 4y ago

> you start creating a complicated network of soft dependencies between those modules. And when you have everything in a single repository, it's hard NOT to do that. That is what the visibility [1] in Bazel solves. You can't import other people's code unless they say you can by making their code visible to yours. [1] https://bazel.build/concepts/visibility https://bazel.build/concepts/visibility