top | item 42078705

(no title)

mcnichol | 1 year ago

Monolith vs Microservice argument all over again.

Tradeoffs for mono are drivers of micro and vice versa.

Looking at the GitHub insights it becomes pretty clear there are about two key devs that commit or merge in PRs to main. I'm guessing this is also whom the code reviews happen etc. Comparing itself to Linux where the number of recurring contributors are more by orders of magnitude just reeks of inexperience. I'm being tough with my words because at face value, the monorepo argument works but it ends in code-spaghetti and heartache when things like developer succession, corporate strategy, market conditions throw wrenches in the gears.

Not for nothing I think a monorepo is perfectly fine when you can hold the dependency graph (that you have influence over) in your head.

Maybe there's a bit of /rant in this because I'm tired of hearing the same problem with solutions that are spun as novel ideas when it's really just: "Pre-optimization is the root of all evil."

You don't need to justify using a monorepo if you are small or close to single threaded in sending stuff into main. It's like a dev telling me: "I didn't add any tests to this and let me explain why..."

The explanation is the admission in my mind but maybe I'm reading into it too much.

Article is nicely written and an enjoyable read but the arguments don't have enough strength to justify. You are using a monorepo, that's okay. Until it's not, that's okay too.

discuss

order

No comments yet.