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.

From learning to earning

Jobs that call for the skills explored in this talk.