The best codebase is the one you fully understand. I prefer codebases that are small enough to understand within a week. This is why I like Microservices. Large codebases can be overwhelming and even senior developers working a decade in the company of might not fully understand them. Instead, I prefer maintaining a few Microservices that our team fully comprehends, where the entire codebase fits into a clear mental model. We then interact with other codebases, that have active mental models in other teams, via APIs.
I'm skeptical of this because I think that a well-architected large codebase should be as good as multiple microservices stapled together at the seams. But then I don't do much web dev.
I agree with you, but the problem is that such codebases rarely exist in practice. This is partly due to laziness and time pressure. When high standards are not maintained or time becomes a constraint, developers start to make compromises in large codebases, such as placing or connecting functionality in inappropriate parts of the codebase. This is much harder to do when access is restricted by an API (contract) between teams, as it forces communication.
Additionally, if parts of the codebase are completely messed up, refactoring in large codebases can be extremely difficult due to complex interconnections with numerous other components. In contrast, with a microservices architecture, if you have 50 microservices and five are poorly designed, you can rewrite them from scratch while ensuring the new versions maintain the same API. This ensures that the other 45 services adhere to the API contract and cannot interfere in any other way.
