Hacker News new | ask | show | jobs
by lukasLansky 2600 days ago
It's a common sense, but it's really hard to argue against super-fine splitting. Having repo per module seems like stronger separations of concerns from a distance.

Of course, what in the end really decides about the strength of your concern separation is the shape of your CI, but alas, repository granuality is just much more visible then CI checks.
1 comments
royjacobs 2600 days ago
I would argue that if you have clear separation of concerns you wouldn't need to make changes in multiple repositories all the time.
link
lukasLansky 2600 days ago
Well let's take frontend/backend separation in a classic webapp -- let's not think about React for now. This makes good concern separation as rendering HTML is something else than computing prices.

If you put frontend and backend into different repositories, you need to make two PRs for every new feature and -- for much worse -- you make integration testing much harder as you don't have atomic product merges to run automation against.

Don't laugh about this example, my corporation is doing stuff like this (backend only repo tightly coupled to frontend repo) all the time.

So maybe we can steelman the argument into "good vertical concern separation doesn't force you into doing multiple PR for single feature, as opposed to horizontal frontend/backend/repository splits."?

But I'm still not sure. Wide integration testing is necesity for reliable microservices. It's difficult to do that with dependencies being out of the scope of the change.

link
royjacobs 2600 days ago
Integrating with other products is something that goes beyond the scope of SCM repository layout, though. If you change your API then clearly someone on the other side also needs to adjust, but that's not simply sending a pull request. That's also making sure you deploy your products in the right order, ensure backwards compatibility and so on.

Re integration testing: That's why things like contract testing are becoming more popular. You make sure that you do as much testing as you can without relying on an entire ecosystem of depdendencies being available, so once you DO release something you can be fairly confident that it's already working as expected.

link
lukasLansky 2600 days ago
I mostly agree. Just notes:

Classic example in favor of monorepos is shared internal library. You should be able to change its API in one step, because that's the way to not having to care about compatibility at all. Compatibility concerns only happen if there's a time difference and with atomic company-wide update, this just doesn't need to happen.

In my example, backend and frontend can be deployed together. And we can discuss whether they should -- I would say there is little benefit of maintaining such single-purpose, wide interface just for getting the ability deploy frontend changes only, but this would depend on care the team put into configuration of cluster orchestration.

Contract testing is good, but not as good as testing against the real thing. Very much depend on the circumstances though.

link