The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.
> The big thing about monorepos in this case is making a change atomic across a set of projects.
The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.
The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world.
The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.
