The Ideal Micro-Frontends Platform

Luca Mezzalira shares a decision framework for micro-frontends, covering composition, routing, and communication. He explains how to structure "stream-aligned" teams and use a "tiger team" for foundational architecture. He also discusses the sociotechnical benefits of reducing external dependencies and shares how to use guardrails and discovery services to achieve 25+ deployments per day.

The Evolution of Micro-Frontends

In 2016, Thoughtworks coined the term "micro-frontends" to address challenges in maintaining large frontend codebases. The concept emerged from recognizing that frontend development faced similar scaling issues to backend microservices.

Micro-frontends are defined as "a technical representation of business subdomain" that allows independent implementation with the same or different technology, minimizes shared code, and is owned by a single team.

Key Principles of Micro-Frontends

Business Subdomain Representation

Unlike components that share knowledge with their containers, micro-frontends encapsulate their state and are context-aware. The container shouldn't know anything about the domain - it should only enable loading a micro-frontend.

Independence Over Reusability

Micro-frontends optimize for fast flow and independent deployments rather than reusability. This means:

• Clear input and output for communication
• Less extensibility compared to components
• Co-located state within each micro-frontend

Testing Boundaries

A useful heuristic: reduce the API exposed to the container to just an ID and event emitter injection. If you need to coordinate deployment across multiple micro-frontends, the domain has likely leaked.

Organizational Benefits

Micro-frontends provide benefits similar to microservices but with a crucial distinction - they're primarily an organizational choice rather than just a technical one.

Conway's Law in Practice

Melvin Conway's observation from 1967 states that system design reflects organizational structure. Distributed systems like micro-frontends enable scaling organizations, not just technology.

Team Topologies

Stream-aligned teams work on specific features, while enabling teams (security, architecture, developer experience) create guardrails. Platform teams provide foundational services and tools.

The Four Foundational Decisions

Every micro-frontends implementation requires answering four key questions:

1. How does a micro-frontend look? - Horizontal split (multiple in same view) vs vertical split (one per view)
2. How do you compose? - Client-side rendering vs server-side rendering
3. How do you route? - Application shell handles routing
4. How do you communicate? - Event emitters, custom events, or reactive streams

Split Strategies

• Vertical split: Start with one micro-frontend per view (recommended for beginners)
• Horizontal split: Multiple micro-frontends in same view (for complex systems)

Communication Patterns

Event emitters are preferred over reactive streams for most teams due to lower complexity. For ephemeral data, use query strings; for session tokens, use cookies.

Platform Team Responsibilities

The platform team defines the foundation for distributed systems. Key responsibilities include:

Application Shell Design

• As vanilla as possible (avoid frameworks when feasible)
• Context unaware
• Low code volatility when stable
• Only responsible for composition and routing

Technology Selection Framework

There's no universal "right" choice - it depends on organizational context:

• Formula One uses Next.js with different caching strategies per micro-frontend
• CDN-based approaches enable module federation or HTML string injection
• Astro islands allow independent server-side rendering of different components

Developer Experience Guardrails

Dependency Management

Use Dependabot for automated updates and ts-arch (porting of ArchUnit) to enforce architectural boundaries.

Performance Budgets

Implement Git hooks that build micro-frontends and check artifact size against thresholds before merging pull requests.

Code Sharing Philosophy

Follow Sandi Metz's principle: "Duplication is far cheaper than the wrong abstraction." Start with duplication, wait 6 months, then abstract based on actual pain points.

Deployment Strategies

Three Characteristics of Ideal Deployment

• Incremental
• Frequent
• Independent

Discovery Service

A JSON schema identifies micro-frontends with URLs, fallbacks, metadata, and deployment strategies. This enables canary releases and blue-green deployments at the network level.

Frontend Discovery Service

An open-source serverless solution that works with any CI/CD system, allowing one-click deployment to AWS accounts.

Value-Stream Team Responsibilities

Technology Selection

Avoid the "micro-frontends anarchy" antipattern - don't optimize for using multiple frameworks in the same application unless absolutely necessary (e.g., acquisitions or migrations).

Ownership Mindset

Teams should own their micro-frontends end-to-end: coding, testing, deployment, monitoring, and observability. This eliminates the "throw over the fence" mentality.

Guardrail Adherence

Teams must follow architectural, security, and platform guidelines rather than going rogue with technology choices.

Implementation Patterns

Initial Decision-Making

Two common patterns:

1. Staff/principal engineers form a virtual team
2. Tiger team with representatives from different teams works together for 8 months, then decentralizes

Rate of Change Considerations

• Logging/analytics libraries: Low rate of change
• Design system: Medium rate of change
• Data layer: High rate of change (domain-specific)

Real-World Impact

Teams have moved from 2 deployments per month to 25+ per team per day by implementing proper guardrails, canary releases, and blue-green deployments. The complexity shifts from writing code to operationalizing the system.

Micro-frontends represent a return to architecture thinking in frontend development, requiring teams to consider governance, observability, end-to-end testing, security, events management, and performance holistically rather than just focusing on UI implementation.

For more insights, Luca maintains a free fortnightly newsletter sharing case studies and community developments in micro-frontends.