From my past experience, micro-frontends were awesome and liberating... in the beginning. Every team gets their own deploy pipeline and can deploy changes independent of each other, with their own error boundaries - awesome!<p>Over time though, the added overhead of micro-frontends really started slowing us down. For eg: instrumenting the web user experience with analytics, across app boundaries in a consistent fashion was a grueling coordination effort with multiple teams. A UI refresh would require coordinated effort across multiple teams. Sure, we had shared components, libraries with common business logic released as their own private packages, etc. But that's the exact overhead I'm talking about. Upgrading a shared dependency across multiple apps was quite the hassle.<p>After a couple of years, we ended up switching back to a monolithic frontend, with a single React app.
> By modularizing our front and back ends in such a way, no one person is responsible for keeping an entire app in their head all the time. As developers, it’s important to have a strong sense of our broader architectural ecosystems<p>Maybe I’m misinterpreting this, but those two sentences contradict themselves in my opinion.<p>Now either developers need to fully understand all the different micro-services, and understand how they all work together. Or developers will lose sight of the bigger architecture and end up specialising in only a few services.<p>But more importantly, I doubt micro-services will solve their problem of their monolith not being modular. That seems like an architectural problem that can also be solved in a monolith.<p>But in general, I have never seen a company that switched to micro-services, and didn’t end up regretting it a few years later.