Micro-frontends anti-patterns

Your micro-frontends might be creating more problems than they solve. Learn to spot and fix the most common anti-patterns before they become deployment bottlenecks.

#1about 3 minutes

Understanding the core benefits of micro-frontend architecture

Micro-frontends enable incremental upgrades, decentralized decision-making, reduced team cognitive load, and scalable organizational structures.

#2about 5 minutes

Anti-pattern: Confusing micro-frontends with reusable components

A micro-frontend represents a business sub-domain and is independently deployable, whereas a component has its behavior dictated by its container.

#3about 2 minutes

Anti-pattern: Using a multi-framework approach incorrectly

While technically possible, using multiple frameworks should be reserved for temporary situations like migrating legacy systems, not for developer preference.

#4about 5 minutes

Anti-pattern: Using an anti-corruption layer for legacy systems

Instead of adding complex, one-off logic to the main application shell, wrap legacy code in a dedicated micro-frontend that acts as an anti-corruption layer.

#5about 4 minutes

Anti-pattern: The risks of shared core libraries

Creating shared core libraries can lead to versioning conflicts and deployment coupling, so prefer composition over inheritance to minimize these risks.

#6about 3 minutes

Anti-pattern: Adopting unidirectional data flow for easier debugging

Bi-directional data sharing between a host and micro-frontends creates complexity, while unidirectional data flow patterns like Flux make state changes predictable.

#7about 2 minutes

Anti-pattern: Avoiding tight coupling with event-based communication

Using a shared global state creates tight design-time coupling between teams; a publish-subscribe (pub/sub) event system enables loosely coupled communication.

#8about 4 minutes

Anti-pattern: Analyzing the backend impact of frontend architecture

When multiple micro-frontends call the same API, it may indicate overlapping domains and cause unnecessary backend load, so consider merging them or using components.

#9about 4 minutes

Viewing software architecture as a series of trade-offs

Architectural decisions are not right or wrong but are based on context-specific trade-offs that should be documented using tools like Architectural Decision Records (ADRs).

#10about 8 minutes

Q&A: MFE communication, monorepos, and appropriate use cases

The discussion covers preferred methods for MFE-to-MFE communication, the trade-offs between monorepos and multi-repos, and when micro-frontends are an appropriate choice.