chipdart

> That would take forever - far too long in our case.

It doesn't. It just does not force everyone to rush both clients and services to prod without having a fallback plan. Also dubbed as competent engineering.

> We have to be able to make changes on the clients of our code because the teams responsible for them are busy achieving their goals.

Yes. That's what you want, isn't it? Otherwise as a service maintainer you'd be blocked for no reason at all.

And let's not even touch the topic of rolling back changes.

There is no way around it. Once you start to think about any of the rationale behind this monorepo nonsense, you soon realize it's a huge mess: lots of easily avoidable problems created by yourself for yourself, that otherwise would be easy to avoid.

> I've witnessed having those packages and versioning only lead down to unmanageable dependency hell.

There is no dependency hell. Your consumers allocate work effort to migrate to the latest version. This is work you would still have to do with a monorepo.

> So you might have to update everything that references your changing API to use the new version....

That's how versioning works.

- You allow legacy applications to consume the legacy interface,

- you provide a new interface to the world so that they have a path forward to migrate out of consuming the legacy service through the legacy interface,

- the consumers migrate in a time frame that makes sense to them.

- in the end you sunset the legacy API, and pull the plug.

This scenario is not eliminated by monorepos.

What monorepos do is force consumers to migrate to the new interface as an urgent task that's part of the critical path. If you have resources to do that migration, it does not matter how you store your code.

> Surely the git SHA is "a form of versioning", isn't it?

If you're consuming a module from a git as a submodule, yes.

> think most people who are poor who voted for Trump expect him to eliminate unnecessary rent-seekers (...)

You mean people vote for a slum lord who is lauded by billionaires expecting and who funelled Whitehouse budget to his own hotels expecting him to eliminate rent-seekers?

> (...) while also putting up barriers to free trade, thus increasing domestic spending (...)

You mean the same guy who sold them cheap made in China golden sneakers for a small fortune, and bragged he got all his loans from Russia?

This train of thought defies any and all reasoning.

> There is a link in this thread that I'll never find that refutes your point. It quotes the bill even.

There isn't. Go read the bill.

Hell, the bill was co-authored by republicans, and even approved by some republicans after Trump told them to sit.

Who falls for this bullshit talking point?

> Versioning introduces a big maintenance cost, both on the side of the developer of a service and on the consumer side.

Not really.

From the producer side it only requires that a) you do not break your contract, b) when you need to break a contract, you bump your version number, c) when no one uses older versions, remove the code.

From the consumer, it's even easier: you just need to point to the version you're consuming.

What exactly do you think is the problem?

> 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.

> 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?

> Sort of; at medium scale you can blue/green your whole system out of the monorepo (even if its say 20 services) in k8s and flip the ingresses to cut over during release.

That's overall a bad idea, and negates the whole point of blue-green deployments. This is particularly bad if you have in place any form of distributed transaction.

There are very good reasons why deployment strategies such as rolling deployments and one-box deployments were developed. You need to be able to gradually roll out a change to prevent problems from escalating and causing downtime. If you use all that infrastructure to then flip global switches then you're building up all this infrastructure to the negate any of that with practices that invariably cause problems.

And this is being done just because someone thinks it's a good idea to keep all code in a single repo?

> My only counter argument here, is when those 4 things deploy independently.

This brings us to the elephant in the room: monorepo strategies are just naive and futile attempts at fixing the problems created by an absolute lack of support for versioning.

If you support versioning, you don't care where and how you store your code. You just push the changes you need to push, and make sure you bump versions to reflect the nature of your changes. Consumers are left with the responsibility of picking which to consume, and when to consume it.

> As soon as you split 1 repo into 2 repos you need to start building tooling to support your 2 repos.

No, not really.

If you're talking about projects for modules and components, all you need is a versioning strategy and release consumable packages of your projects.

If you're talking about services, all you need to do is support versioned APIs and preserve your contracts.

No tooling required. For projects you can even make do with git submodules. For services, all you need to do is update clients of your downstream dependencies.

What problems are you facing, exactly?

> I prefer microservices/microrepos _conceptually_, but we had the same experience as your quoted text - making changes to four repos, and backporting those changes to the previous two release branches, means twelve separate PRs to make a change.

You only need to coordinate this sort of changes if you have absolutely no versioning strategy in place and accept breaking contracts for no reason at all.

If you have any form of versioning in place, you do not need to push multi-project commits. You update upstream packages and services, roll them out, and proceed to update the projects that consume them to gradually point them to the newly released versions.

> 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.

From the article:

> Let’s also remember that reviewers aren’t always right—even when the majority opinion disagrees with the code author. After weeks (sometimes longer) spent tackling a problem, the code author is usually the most qualified in that specific problem’s domain, unlike team members or leads who’ve only engaged with it for the hour or so it takes to review the code. More often than not, it’s better to trust the code author’s judgment.

What a shit take. Code reviewers ask questions and point out issues. If your PR includes errors and fails to address problems that reviewers were able to spot just by looking at them, it means nothing how much time you took working on it. Just fix it instead of sulking in blog posts.

And then this gem.

> In fact, I’d argue that the code author, by virtue of their time and effort, deserves the chance to see their proposals in action.

What is this? A participation medal? It means nothing how much time and effort you invested. If your PR has errors and introduces obvious bugs and fails to comply with anything, just fix it. Push a commit that addresses remarks and learn from it. Or are you expecting your team members to post follow-up commits to fix the mess you are making? Perhaps you're just hoping to block pipelines when automated tests fail?

Absurd.

> We were talking about dev enviroments on desktops, not independently scalable components.

Your dev environment is expected to mimick your production environment, not the other way around.

> The border deal provided amnesty that is clearly NOT in the interests of uneducated and poor citizens.

You should inform yourself about the bipartisan border bill that Trump killed at the last moment. The "amnesty" thing only exists as a propaganda talking point. The bill tightened up requirements for asylum and imposed automatic deportation rules.

> In part, maybe. And at the very end of the list of proposal, (...)

Not in part.

And now you voted on the guy whose only concrete economic policy is to massively drive up inflation by imposing tariffs.

> Closing border, halting illegal immigration, mass deportations - these are massively net positive for US citizens who are uneducated and poor. Migrates are competing with them for jobs, housing, social services, all resources.

If that was really the case how come you just elected the very same guy who killed the border deal?

> Ending forever wars will allow shifting of budget priorities. A reduction of just 10-15% of defense and intelligence budgets and cutting funding to Israel and Ukraine can pay for childcare for every child in the US easily.

There is no "funding to Israel and Ukraine". For Ukraine there's transfer of outdated weapon systems reaching the end of life and already obsolete, which in turn is creating jobs in the US to restock and replenish the US's arsenal. If anything, you're seeing money go into the US defense industry which ends up being the US's take on welfare and social security program with all the pork programs.

Whoever fooled you into believing people are handing over cash to Ukraine, fooled you very well.

> Still refusing to listen to us plebeians. I can't afford groceries. I'm not looking for a scholar-bureaucrat reframe of my problem. I'm looking for a solution.

What solution do you expect from Trump?

> To give credit where credit is due, Trump successfully switched the Republican party away from the being the party of expansionist war.

That's mainly because Trump is a Russian asset and it's in Putin's best interests to manipulate the US to yield and capitulate to his demands to betray allies. So under the bullshit excuse of being isolationist and pro-peace, you'll see Trump ultimately ensure Ukraine ceases to exist, NATO is dismantled, and war ravages through eastern and western Europe.

> Given the modern hiring practice of "can you pass Leetcode," and "can you memorize and regurgitate how to architect a link shortener," yes, yes I do.

You are contradicting yourself. If there's anything that requires studying and preparation, that's leetcode.

Also, "memorize and regurgitate how to architect a link shortener" is also known as learning and knowing the basics of systems architecture and software architecture. That's an odd way of criticising others for being more competent than you.

> This is a bad idea.

Not really. It all depends on what are your needs.

> It defeats a major feature of the jvm.

You're confusing things. Just because Java addressed the deployability problem for Java applications before containerization was even a word, this does not mean that deploying a JVM per service is a bad idea. Just think about it for a second. Why do you need to deploy and scale services independently? Do you mention the JVM in your response? No.

> I think nobody really talks about this, but unless you have a docker-compose.yml that includes everything you need for local development (...)

Is this a problem?

I mean, in this scenario docker compose serves two main purposes: launch a few mock services, and configure those services according to your needs. This means configuring them to consume services already deployed to a cloud environment of your choice. This is something you control.

Then all that's left is the service (or set if services) you need to modify. You run those locally and configure them to consume a mix of the mocked services and the services deployed to a cloud environment.

> (...) it's increasingly more likely that you'll end up coupling things to Kubernetes to such a degree that running without it (and its abstractions) will become more effort than a person can muster.

That coupling can only happen if you intentionally add it yourself.

If you need to run your services in isolation, you will be more mindful of the need to not introduce that sort of coupling.

> How do you do that without first running all the services (...)

Why do you need to run all services in isolation to be able to troubleshoot and isolate a problem?

> Only if you cannot change one service without changing the other simultaneously.

Not true at all.

You're conflating the need for distributed transactions with the definition of microservices. That's not it.

> Multiple services connecting to the same database has been considered a bad idea for a long time.

Not the same thing at all. Microservices do have the database per service pattern, and even the database instance per service instance pattern, but shared database pattern is also something that exists in the real world. That's not what makes a microservice a microservice.

> If the microservice has dependencies on other services it is not a microservice.

You should read up on microservices because that's definitely not what they are not anything resembling one of their traits.

> You don’t have to test them all end to end before merging a PR.

You have to test the changes you want to push. That's the whole basis of CI/CD. The question is at which stage are you ok with seeing your pipeline build.

If you accept that you can block your whole pipeline by merging a bad PR then that's ok.

In the meantime, it is customary to configure pipelines to run unit, integration tests, and sometimes even contract tests when creating a feature branch. Some platforms even provide high-level support for spinning up sandbox environment as part of their pipeline infrastructure.

> Your whole argument boils down to "don't write shit software" (...)

No. My whole argument is open your eyes, and look at what you're doing. Make it make sense.

Does it make sense to launch 50 instances locally to be able do work on a service? No. That's a stupid way of going about a problem.

What would make sense? Launch the services you need to change, of course. Whatever you need to debug, that's what you need to run locally. Everything else you consume it from a cloud environment that's up and running.

That's it. Simple.

If there's something preventing you from doing just that then that's an artiicifal constraint that you created for yourself, and thus that you need to fix. We're talking about things like auth. Once you fix that, go back to square one.

> This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing".

No, not really. You only find yourself in that spot if you completely failed to do any semblance of integration test, or any acceptance test whatsoever.

That's not a microservices problem. That's a you problem.

You talk about feedback look. Other than automated tests, what do you believe that is?