DEV Community

Cover image for Top 10 Micro Frontend Anti-Patterns

Top 10 Micro Frontend Anti-Patterns

Florian Rappl on March 20, 2024

Photo by Markus Spiske on Unsplash Every year more and more companies switch over to micro frontends. While organizational benefits are (or rath...
Collapse
 
aleksanderlubych profile image
Aleksander Lubych

What is worth mentioning is that sometimes it is worth to have the governance model around MFE in place, e.g. you pointed out that observability is important and we need to have some visibility and debugging available in the Micro Frontends. That would be part of the governance as a "must have" for the MFE's owners.

The governance model might be some kind of contract between the platform owners and the MFE which allows to turn off the MFE if its not following the model.

Its not an anti pattern to not have the governance, BUT it might be extremely handy sometimes :)

Collapse
 
florianrappl profile image
Florian Rappl

I fully agree. Actually, governance is one of the things I also touch my book and I personally fully share your opinion.

Being able to (centrally) control the MFs is crucial - even though teams should be autonomous it's still ONE solution that is seen / shipped by the end-users as ONE product / application; so having also some central control over it is essential.

Collapse
 
aleksanderlubych profile image
Aleksander Lubych

Absolutely!

Collapse
 
alxwnth profile image
Alex

Excellent in-depth article!

Collapse
 
cmcnicholas profile image
Craig McNicholas

Nice article, one point I don't see is about treating your micro frontend no different to an API. It should be a contract and you should avoid breaking changes and design for backwards compatibility. If you can't then at least follow an expand/contract approach to add new breaking functionality.

I've been doing this in a large Vue monorepo for years now and have hit a real sweet spot with decoupling changes across the teams and contributors and not breaking the build. Albeit we don't deploy our microfrontends independently the same rules apply.

Thanks for taking the time to write.

Collapse
 
florianrappl profile image
Florian Rappl

Yes this is a good point - actually the anti-patterns for microservices do overlap vastly with the anti-patterns for MFs; so also in this regard the underlying details may be different, but overall its quite similar. Likewise, events & components etc. are your API here - treat them like that!

Contract-based testing is something that has become almost "natural" for microservices - I think this will happen with MFs, too.

Thanks for pointing this out.