[jabo]

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!

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.

After a couple of years, we ended up switching back to a monolithic frontend, with a single React app.

[tutfbhuf]

Wouldn't it be possible to just have one styling package maintained by one team for all other teams?

[jabo]

Yup, that's the overhead I'm referring to. With a platform team at play, you now have an extra dependency for all other teams - both technical and communication-wise - and that adds some friction.

The question is, are the efficiencies gained more than the added friction/overhead. In our case, the answer was no. So we moved away from micro-frontends.

[tutfbhuf]

How do you handle important libraries (common functionality) for your teams in the backend?

Sure, it's possible to remove all dependencies from a teams project by copy and pasting the code or by reinventing the wheel, but I'm not sure if these options are better than carefully chosen dependencies (including some maintained by other teams).