[azemetre]

There’s also project repos where all the code pertaining to a project is under one repo. I think this setup is the best of both worlds.

If you’re a team that has a client, several micro services, DB, etc it’s way better to have that under a single repo than spread to multiple. Monorepos don’t have to be gigantic monstrosities, they can encapsulated products.

[lucasyvas]

I like to call this a "macroservice" or "business function" repository. If you are dealing with the Billing function, everything to do with that is in the billing repository (UI, API, scripts, workers/jobs, database migrations).

This is my favorite for sure in terms of balance - you don't need the overhead of one repo per deployable artifact, and the size of the repository has a reasonable theoretical maximum and can still come close to fitting in your head.

You can also test it all together extremely easily and it's the perfect slice for a team to work on, or be shoveled off to a different owner of that function in the future.

[8note]

I'd certainly prefer to keep each microservice in its own repo.

That way in a reorg, the services can be redistributed in a way that makes sense without having to make code changes.

Having two monorepos where you only own half of each seems like the worst of both worlds

[azemetre]

What if your team is the only ones that consume the micro service? Doesn’t make sense to me to split it. It’s also way easier to take stuff out of monorepos than put them in IMO.

[drewcoo]

> I'd certainly prefer to keep each microservice in its own repo.

Having a single monorepo solves that, too.