I find this stuff to be utterly overkill unless you are building the next Bloomberg terminal (say) and have completely separate teams. Or you have more than say 100 frontend coders working on the same codebase.
If you think you need micro services you are unlikely to need a micro frontend for another order of magnitude of scale. The people talking about both of these things never seem to point out the downsides and huge delivery overheads to these approaches. Much better to make sure you are doing everything perfectly on a single codebase before you take high risk, difficult to manage decisions because you read how cool it was on Martin Fowler’s blog.
Not to mention that you get many of the supposed benefits of "micro frontends" by just applying good engineering practices to a monolith. You can easily have independent teams and incremental changes by splitting your application into mostly independent packages without having them live in their own applications.
Working on big frontend apps is painful, upgrade paths are painful, deprecating packages is painful, testing and debugging is painful.
As with microservices, you don't start with 1000 services, but logically being able to split them when needed.
"delivery overheads to these approaches" as a matter of fact it's harder to deploy monoliths (as all the parts have to sync) than with microfrontends (that follow semver). As each group can have independent deployments.
"make sure you are doing everything perfectly", unfortunately, is what no one has ever been able to do in the history of coding, despite the claims :)
To clarify I'm obviously saying you need to make your development practices as good as they can be (specification, testing, deployment, dependancies, reviews, documentation etc.) rather than thinking microfrontends will solve your issues. I didn't really mean perfect if you want to be that pedantic.
>>> it's harder to deploy monoliths
Evidence? I argue and have seen repeatedly that duplicating across services/frontends the work of "upgrade paths [...], deprecating packages [...], testing and debugging" as well as styles, databases, configuration, and most importantly transactions/shared state causes all kinds of problems.
You state that everyone chooses a sensible path to splitting up software, I'm saying they don't, they go straight to drinking the whole bottle of cool aid and almost never seem to take reasonable approaches to balance the needs of transactionality or simplicity in their systems and instead go straight to full on architecture astronaughting.
If you think you need micro services you are unlikely to need a micro frontend for another order of magnitude of scale. The people talking about both of these things never seem to point out the downsides and huge delivery overheads to these approaches. Much better to make sure you are doing everything perfectly on a single codebase before you take high risk, difficult to manage decisions because you read how cool it was on Martin Fowler’s blog.