Microfrontends should be a last resort

Micro-anything tends to cause engineering orgs to spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box than actually considering their users needs.

The killer truth is, the connections between your components start to become more important than the components, and the work to maintain this system is only really justifiable if the components can be worked on in parallel.

But that never happens, and now you spend all your time trying to herd cats. Embrace a monolith, modularise the code, discuss your work with your colleagues so you don't step on each others' toes.

We're here to build systems, not pet-projects/fiefdoms. There is no software architecture that will allow you to work in isolation.

> So let’s say our frontend app is a hairball that’s full of interdependencies. How do we break that link? I think engineers - and managers! - are so excited about the prospect of escaping the monolith, they forget about the intermediary stage of actually chopping up the hairball.

Absolutely this, true in both the back and front ends. The first step to breaking apart any monolith is the extremely boring refactoring process. People want to skip over this because it's not the sexy cool part where you're using Kubernetes and lambdas or whatever other tech will look great on your resume. But I'll say that every monolith->microservice (or MFE) move that I've seen, whether or not it was successful was entirely determined by if the upfront refactoring work was done.

Separate services helps a lot with bigger teams. No matter how much you modularize code -- which will gradually fall apart anyway unless you have custom tooling that enforces API boundaries programmatically -- you're still tying people to the same runtime environment, which means you're tying people to the same libraries and underlying framework/operating system. Which means major library upgrades become nonstarters (too much code to test/change), and runtime upgrades are rare and challenging (hello, enterprises still running Java 6/7).

There's a balance and the "every function should be a microservice" approach is kind of insane, but "just use a monolith for everything" falls apart pretty quickly at larger team sizes.

These blanket statements on Hackernews are so frustrating to read. Every one of these articles is bait for these type of comments. The comments fill up with people saying microservices suck, then it fills up with comments saying those comments suck.

Please understand that every environment, company, and project is different.

I think there's more fruitful discussions to be had, e.g. which editor is to be preferred or which programming language is best.