3 ms·

Working on big frontend apps is painful, upgrade paths are painful, deprecating packages is painful, testing and debugging is painful. As with microservices, yo

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 :)

andy_ppp 7y ago
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.