Micro frontends: A cure or a new catalyst for baldness?

The micro-frontend architecture has recently sparked a wave of enthusiasm in the frontend domain, promising to solve the bloat of monolithic applications while introducing new technical challenges. Teams enjoy independent development and deployment but also face difficulties such as style isolation, state sharing, and performance optimization. Is this the savior of large-scale frontend projects or a trap that makes developers lose more hair?

Core Concepts and Implementation Methods of Micro-Frontends

Micro-frontends are essentially a technical architecture that combines multiple independent functional modules into a complete application. Similar to microservices, they emphasize technology stack independence, independent development, and deployment. Current mainstream implementation solutions include:

1. Route Distribution: Routing to different sub-applications via Nginx or reverse proxies
2. iframe Embedding: A traditional but highly isolated solution
3. Web Components: Leveraging the browser's native component capabilities
4. Module Federation: An innovative solution introduced by Webpack 5
5. Framework Integration: Open-source solutions like single-spa and qiankun

// qiankun main application configuration example
import { registerMicroApps, start } from 'qiankun';

registerMicroApps([
  {
    name: 'reactApp',
    entry: '//localhost:7100',
    container: '#subapp-viewport',
    activeRule: '/react',
  },
  {
    name: 'vueApp',
    entry: '//localhost:7101',
    container: '#subapp-viewport',
    activeRule: '/vue',
  }
]);

start();

Significant Advantages of Micro-Frontends

Technology Stack Agnosticism

Different teams can choose suitable technology stacks based on their needs. Legacy projects can continue using AngularJS, new modules can adopt React 18, and even some pages can experiment with SolidJS. An e-commerce platform seamlessly integrated product detail pages (Vue), shopping carts (React), and payment flows (Svelte), significantly reducing the cost of technology upgrades.

Independent Development and Deployment

Each sub-application has its own CI/CD pipeline. Meituan's delivery team achieved independent deployment for 200+ sub-applications through micro-frontends, increasing release frequency from once a week to over 20 times daily. Errors in one sub-application do not affect the overall system availability.

Incremental Migration

Particularly friendly for legacy system modernization. A financial institution gradually replaced a 10-year-old jQuery system by first attaching React components, then migrating modules step by step, ultimately achieving a smooth transition.

Thorny Problems Encountered in Practice

CSS Style Pollution

Even with Shadow DOM, global styles can still leak. One project encountered a case where a sub-application modified the body font, causing layout issues in the main application:

/* Dangerous code in a sub-application */
body {
  font-family: 'SomeFont' !important;
  line-height: 1.2;
}

Solutions include:

• Adopting BEM naming conventions
• Using CSS-in-JS solutions
• Adding application prefix transformation tools

State Management Challenges

Cross-application state sharing becomes complex. User login states need to be synchronized between the main application and all sub-applications:

// Custom event-based communication solution
// Main application
const store = {
  user: null,
  setUser(user) {
    this.user = user;
    window.dispatchEvent(new CustomEvent('global-user-change', { detail: user }));
  }
}

// Sub-application
window.addEventListener('global-user-change', (e) => {
  console.log('User changed:', e.detail);
});

Performance Optimization Challenges

Resource duplication is a prominent issue. Three React sub-applications might cause React to be loaded three times. One project reduced the first-screen load time from 8s to 3s by optimizing with externals and module federation:

// Webpack module federation configuration
new ModuleFederationPlugin({
  name: "host",
  remotes: {
    app1: "app1@http://localhost:3001/remoteEntry.js",
    app2: "app2@http://localhost:3002/remoteEntry.js"
  },
  shared: {
    react: { singleton: true },
    "react-dom": { singleton: true }
  }
})

New Dimensions of Team Collaboration

The micro-frontend architecture profoundly impacts team collaboration models. Practices from a multinational enterprise reveal:

1. Contract Definition: Clear API specifications between applications must be defined.
2. Design System: A unified UI component library must be established.
3. Monitoring System: Error tracking needs to distinguish responsibility boundaries.
4. Performance Budget: Each sub-application should have explicit resource limits.

Typical problem scenarios:

• Sub-application A uses a 2MB moment.js localization file.
• Sub-application B imports the full lodash library.
• Sub-application C's chunks lack code splitting.

Key Factors in Decision-Making

Before implementing micro-frontends, consider:

1. Team Size: Small teams may find it counterproductive.
2. Project Complexity: Simple SPAs may not need micro-frontends.
3. Technology Heterogeneity: Whether multiple frameworks need to coexist.
4. Infrastructure: Whether robust DevOps support is available.

Example evaluation matrix:

Future Evolution Directions

Emerging technologies are reshaping micro-frontend practices:

1. Module Federation 2.0: A lighter solution proposed by Webpack.
2. Vite Ecosystem Integration: Better development experience based on ESM.
3. Edge Computing: Dynamic nearby loading of sub-applications.
4. WebAssembly: Incorporating non-JS applications into the micro-frontend system.

// Vite-based module federation example  
// vite.config.js  
import { defineConfig } from 'vite'  
import federation from '@originjs/vite-plugin-federation'  

export default defineConfig({  
  plugins: [  
    federation({  
      name: 'host-app',  
      remotes: {  
        remoteApp: 'http://localhost:5001/assets/remoteEntry.js'  
      },  
      shared: ['vue']  
    })  
  ]  
})  

Hard-Earned Lessons from the Real World

A fintech company's post-migration insights:

1. Version Locking Disaster: The main application locked React at 16.8, preventing sub-applications from using Hooks.
2. Type Definition Conflicts: Incompatible @types/react versions across sub-applications.
3. Build Tool Differences: Webpack 4 sub-applications couldn't consume Webpack 5's module federation.
4. Monitoring Blind Spots: Sentry couldn't correctly associate errors with sub-applications.

Their solutions included:

• Establishing version control mechanisms for core dependencies.
• Developing a unified SDK to encapsulate common dependencies.
• Building a cross-application performance monitoring platform.
• Setting strict acceptance criteria for sub-applications.