4 ms·

> IMO, this is a huge quality of life improvement and prevents a lot of mistakes from not having the right revision synced down across different repos. This alo

> IMO, this is a huge quality of life improvement and prevents a lot of mistakes from not having the right revision synced down across different repos. This alone is a HUGE improvement where a dev doesn't accidentally end up with one repo in this branch and forgot to pull this other repo at the same branch and get weird issues due to this basic hassle. This scenario only happens if you're working with a distributed monolith, you care nothing about breaking existing APIs, and you own all producers and consumers. When this happens, your problem is obviously not how you maintain projects independently in separate repos. Your problems is how you're failing to preserve API contracts, and instead you go to the extreme of insisting in breaking all contracts at once. It's also a huge red flag when you talk about "accidentally end up with one repo in this branch". Don't you know what you are pushing to production? As always, monorepo talks are just a thin veil of optimization placed over a huge mess of major operational and technical problems.

The_Colonel 2y ago
> Your problems is how you're failing to preserve API contracts, and instead you go to the extreme of insisting in breaking all contracts at once. Preserving contracts has a significant cost. Why would you try to preserve contracts if you're in fact in control of all producers and consumers?
- chipdart 2y ago
  > Preserving contracts has a significant cost. Not really. You just need to break out a new version when you put out a breaking change. This can mean anything between duplicating the code that implements your interface to then apply a change and checking a version flag when invoking an operation to determine which version to run. Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? > Why would you try to preserve contracts if you're in fact in control of all producers and consumers? Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. Also, as others have pointed out, storing code in the same repository gives you no assurance that all your services will be deployed at the same exact moment in time. Consider for example multi-region deployments, or even deployments to multiple availability zones. Those aren't atomic. Why does anyone believe that storing all code in the same repository is enough to make these operations atomic?
  - friendzis 2y ago
    > Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? Not isolated to this particular issue. People really like to pretend that problems are much simpler than they actually are and that inherent complexity is just some edge cases to be ironed out.
    - The_Colonel 2y ago
      What is an edge case, what is an accepted outage window, failure rate etc. depends on the specific case. On one end you have Netflix-like architectures, on the other end you have intranet apps used twice monthly by two users. There's a wide range of needs and expectations in between.
  - The_Colonel 2y ago
    > Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? Yes, but my time is limited and there's the opportunity cost. It also means more code, more tests for future. More code, ceteris paribus, represents more maintenance costs for the future. > Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. I can prevent things from breaking in multi-repo, multi-versioned architecture, it's just more expensive to do so.
  - lolinder 2y ago
    > Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? No one is saying that. But there are lots of types of shared code that can be updated atomically, so why not update them atomically? And there's nothing inherent in being a monorepo that prevents you from being careful about the non-atomic updates. It's really easy to accidentally deploy multiple repos in a way that gets the deployment order wrong. You have to be careful with non-atomic deployments whatever type of repo structure you have.
stefan_ 2y ago
API contracts are not free, and for things that were not decided to be an API and or a contract an absolute waste of time. Of course I’m “breaking all contracts at once”, for most of them were never a contract to begin with, and the monorepo effectively discourages people from assuming random behaviors are in fact contracts, and that preserves my sanity and the sanity of the code base that now doesn’t suffer from the combinatorial explosion in complexity that happens when people want everything to be an API contract.
- chipdart 2y ago
  > API contracts are not free Yes, they are. They are as free as adding a new endpoint. > and for things that were not decided to be an API and or a contract an absolute waste of time. You're talking about integrating multiple projects. There are always contract. You simply chose to be ignorant of that fact and fail to interpret breaking those contracts as the root cause of all your problems. You point out anyone lauding monorepos as some kind of solution to any problem and I assure you that we can immediately isolate one or more problems caused by versioning and breaking contracts. The only reason why we see this nonsense paraded in web services is that they are loosely coupled. When people worked mainly with modules and libraries, compiler and linking errors made this sort of error very obvious. Now people chose to unlearn facts and want to call that operational improvements.
  - LinXitoW 2y ago
    > There are always contract. You simply chose to be ignorant of that fact and fail to interpret breaking those contracts as the root cause of all your problems. This reminds me a lot of the dynamic vs. static typing discussion. Even at a function level, there's always a contract, no other option. The only decision you can make is whether it should be well documented, compiler verifiable and explicit, or not.
  - r1cka 2y ago
    I've found referring to them as implicit vs explicit contracts conveys the idea and is more well received than proclaiming someone's ignorance.

The_Colonel 2y ago

> Your problems is how you're failing to preserve API contracts, and instead you go to the extreme of insisting in breaking all contracts at once. Preserving contracts has a significant cost. Why would you try to preserve contracts if you're in fact in control of all producers and consumers?

chipdart 2y ago
> Preserving contracts has a significant cost. Not really. You just need to break out a new version when you put out a breaking change. This can mean anything between duplicating the code that implements your interface to then apply a change and checking a version flag when invoking an operation to determine which version to run. Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? > Why would you try to preserve contracts if you're in fact in control of all producers and consumers? Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. Also, as others have pointed out, storing code in the same repository gives you no assurance that all your services will be deployed at the same exact moment in time. Consider for example multi-region deployments, or even deployments to multiple availability zones. Those aren't atomic. Why does anyone believe that storing all code in the same repository is enough to make these operations atomic?
- friendzis 2y ago
  > Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? Not isolated to this particular issue. People really like to pretend that problems are much simpler than they actually are and that inherent complexity is just some edge cases to be ironed out.
  - The_Colonel 2y ago
    What is an edge case, what is an accepted outage window, failure rate etc. depends on the specific case. On one end you have Netflix-like architectures, on the other end you have intranet apps used twice monthly by two users. There's a wide range of needs and expectations in between.
- The_Colonel 2y ago
  > Do you struggle to not break your code? To me it's like the main responsibility of any developer, isn't it? Yes, but my time is limited and there's the opportunity cost. It also means more code, more tests for future. More code, ceteris paribus, represents more maintenance costs for the future. > Because you clearly aren't in control, if you feel compelled to dump anything and everything in the same repository to try to prevent things from breaking. I can prevent things from breaking in multi-repo, multi-versioned architecture, it's just more expensive to do so.
- lolinder 2y ago
  > Why does anyone believe that storing all code in the same repository is enough to make these operations atomic? No one is saying that. But there are lots of types of shared code that can be updated atomically, so why not update them atomically? And there's nothing inherent in being a monorepo that prevents you from being careful about the non-atomic updates. It's really easy to accidentally deploy multiple repos in a way that gets the deployment order wrong. You have to be careful with non-atomic deployments whatever type of repo structure you have.

stefan_ 2y ago

API contracts are not free, and for things that were not decided to be an API and or a contract an absolute waste of time. Of course I’m “breaking all contracts at once”, for most of them were never a contract to begin with, and the monorepo effectively discourages people from assuming random behaviors are in fact contracts, and that preserves my sanity and the sanity of the code base that now doesn’t suffer from the combinatorial explosion in complexity that happens when people want everything to be an API contract.

chipdart 2y ago
> API contracts are not free Yes, they are. They are as free as adding a new endpoint. > and for things that were not decided to be an API and or a contract an absolute waste of time. You're talking about integrating multiple projects. There are always contract. You simply chose to be ignorant of that fact and fail to interpret breaking those contracts as the root cause of all your problems. You point out anyone lauding monorepos as some kind of solution to any problem and I assure you that we can immediately isolate one or more problems caused by versioning and breaking contracts. The only reason why we see this nonsense paraded in web services is that they are loosely coupled. When people worked mainly with modules and libraries, compiler and linking errors made this sort of error very obvious. Now people chose to unlearn facts and want to call that operational improvements.
- LinXitoW 2y ago
  > There are always contract. You simply chose to be ignorant of that fact and fail to interpret breaking those contracts as the root cause of all your problems. This reminds me a lot of the dynamic vs. static typing discussion. Even at a function level, there's always a contract, no other option. The only decision you can make is whether it should be well documented, compiler verifiable and explicit, or not.
- r1cka 2y ago
  I've found referring to them as implicit vs explicit contracts conveys the idea and is more well received than proclaiming someone's ignorance.