Micro-frontends anti-patterns

Is your micro-frontend architecture just a distributed monolith in disguise? Learn the common anti-patterns that couple teams and how to build for true independence.

#1about 3 minutes

A brief history of the micro-frontend architectural pattern

The evolution of micro-frontends is traced from early implementations like Zalando's Taylor.js to its recognition by ThoughtWorks and InfoQ.

#2about 3 minutes

Understanding the key benefits of micro-frontend architecture

Micro-frontends enable incremental upgrades, decentralized decision-making, and reduced team cognitive load by aligning architecture with organizational structure.

#3about 4 minutes

Differentiating between domain-aware micro-frontends and components

A micro-frontend represents a business subdomain and is independent, whereas a component is a reusable UI element configured by its container.

#4about 3 minutes

Avoiding the multi-framework trap in micro-frontends

Using multiple UI frameworks should be a temporary strategy for specific scenarios like legacy migration or company acquisitions, not a default choice.

#5about 4 minutes

Using an anti-corruption layer for legacy system integration

When integrating a legacy system, use an anti-corruption layer like an iframe to isolate it and translate its communication patterns, preventing contamination of the main application.

#6about 5 minutes

Managing the complexity and risk of shared libraries

Shared libraries create tight coupling and versioning challenges, so prefer duplication over premature abstraction and use dependency injection for necessary sharing.

#7about 3 minutes

Adopting unidirectional data flow for better debugging

Bidirectional data flow between a host and remote micro-frontend creates complexity, while a unidirectional flow simplifies debugging and reduces errors.

#8about 3 minutes

Preventing organizational coupling caused by shared global state

Sharing a global state across micro-frontends couples development teams together, so use loosely coupled communication methods like an event emitter instead.

#9about 3 minutes

Avoiding self-inflicted load by consolidating API calls

Having multiple micro-frontends call the same API endpoint creates unnecessary backend load, so consolidate these calls into a single parent micro-frontend or component.

#10about 1 minute

Recognizing that architectural decisions are context-dependent trade-offs

There are no universally right or wrong architectural choices, as the validity of a pattern depends entirely on the specific project context and organizational needs.

#11about 13 minutes

Audience Q&A on practical micro-frontend challenges

The speaker answers audience questions on topics including using iframes, splitting monoliths, designing for future scalability, and comparing composition tools.