I think that when you have large enough systems that works. I do not believe that "microservice" is the right size for repo splits.

Sometimes you have to ship a feature. Shipping that requires changing 3 parts of your app. A lot of times that _entire_ set of changes is less than 100 lines of code.

Having a full vision of what is being accomplished across your system in one go is very helpful for reviewing code! It justifies the need for changes, makes it easier to propose alternatives, and makes the go/no-go operation much more straightforward.

At a smaller scale, you often see the idea of splitting frontend and backend into separate repos. Of course you can ship an API and then ship the changes to the frontend. But for a lot of trivial stuff, just having both lets you actually see API usage in practice.

I think this is much more applicable for companies under 100 people though. When you get super large you're going to put into place a superstructure that will cause these splits anyways.

TBH, I am not a fan of frontend/backend split either: ideally, you'd still be splitting per component/service, so frontend and backend for a single thing could live in the same place: you get the benefit of seeing the API in use with each PR, without the costs of monorepo otherwise.

Most projects start out as monoliths (which is good) and splitting up on this axis is unfortunately very hard/costly.

This is why I'm a fan of tools like Bazel, where you can still get most of the tooling benefits from a single repo, but get testing speed benefits (and, if you roll that way, the design benefits from the separation) of a multirepo setup.

Unfortunately it's hard for me to recommend Bazel, it's such an uphill climb to get things working within that system.