undefined | Better HN

0 pointsazemetre3y ago0 comments

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.

0 comments

lucasyvas3y ago

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.

8note3y ago

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

azemetreOP3y ago

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.

drewcoo3y ago

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

Having a single monorepo solves that, too.

j / k navigate · click thread line to collapse