微前端架構概覽

什麼是 Micro-Frontend、為什麼需要它，以及主流架構模式的比較

Overview##

想像一個電商網站：首頁、商品頁、購物車、結帳、會員中心。在傳統的 monolithic frontend 架構下，這些全部打包在同一個 SPA 裡，由同一個團隊、同一個 repo、同一個 CI/CD pipeline 管理。

當團隊從 5 人長到 30 人，問題就來了：

• 一個人改了購物車的程式碼，整個網站都要重新 build 和部署
• 三個團隊要同時 merge 到同一個 main branch，衝突不斷
• 想把商品頁從 React 15 升級到 React 19，但購物車還沒準備好，只能一起等

Micro-Frontend 就是把後端微服務的概念搬到前端：每個功能區塊是獨立的應用，可以由不同團隊獨立開發、測試、部署。

Architecture##

核心原則###

graph TD
  subgraph Monolith
    A[Single SPA] --> B[Homepage]
    A --> C[Product Page]
    A --> D[Cart]
    A --> E[Checkout]
  end

  subgraph Micro-Frontend
    F[Shell / Host] --> G[Team A: Homepage]
    F --> H[Team B: Product Page]
    F --> I[Team C: Cart + Checkout]
  end

Micro-Frontend 的核心原則：

主流整合模式###

實現 Micro-Frontend 有多種方式，每種都有不同的取捨：

1. iframe####

最古老也最簡單的方式 — 每個 micro-frontend 放在一個 <iframe> 裡。

<!-- Shell application -->
<nav><!-- global navigation --></nav>
<main>
  <iframe src="https://team-a.example.com/product-page" />
</main>

優點： 完全隔離，技術完全無關，每個 iframe 是獨立的瀏覽器 context。

缺點： 效能差（每個 iframe 載入完整的 HTML/CSS/JS）、無法共享 state、SEO 困難、使用者體驗差（無法跨 iframe 做動畫或共享樣式）。

2. Web Components####

每個 micro-frontend 包裝成 Custom Element，透過 Shadow DOM 實現樣式隔離。

// Team B: Product Card as Web Component
class ProductCard extends HTMLElement {
  connectedCallback() {
    const shadow = this.attachShadow({ mode: 'open' });
    const productId = this.getAttribute('product-id');

    shadow.innerHTML = `
      <style>
        .card { border: 1px solid #e5e7eb; padding: 16px; }
      </style>
      <div class="card">
        <h3>Product ${productId}</h3>
        <slot name="actions"></slot>
      </div>
    `;
  }
}

customElements.define('product-card', ProductCard);

<!-- Shell: use the Web Component -->
<product-card product-id="42">
  <button slot="actions">Add to Cart</button>
</product-card>

優點： 瀏覽器原生支援、樣式天然隔離、框架無關。

缺點： SSR 支援有限、跨 micro-frontend 共享狀態需要額外方案（Custom Events 或 shared store）、Shadow DOM 的樣式隔離有時反而讓全域主題很難套用。

3. Module Federation####

Webpack 5 / Rspack 內建的功能。每個 micro-frontend 是一個獨立的 webpack build，在 runtime 動態載入彼此的模組。

// Team A: expose a component
// webpack.config.ts
new ModuleFederationPlugin({
  name: 'productApp',
  filename: 'remoteEntry.js',
  exposes: {
    './ProductCard': './src/components/ProductCard',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.0.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
  },
});

// Shell: consume the remote component
const ProductCard = React.lazy(
  () => import('productApp/ProductCard')
);

function App() {
  return (
    <React.Suspense fallback={<div>Loading...</div>}>
      <ProductCard productId="42" />
    </React.Suspense>
  );
}

優點： 可以共享依賴（React 只載入一份）、開發體驗接近 monolith（直接 import）、支援 TypeScript 型別。

缺點： 綁定 webpack / Rspack 生態系、設定有學習門檻、shared dependency 版本衝突需要仔細管理。

模式比較###

通訊模式###

不管用哪種整合方式，micro-frontend 之間總需要溝通。常見的做法：

graph LR
  A[Product Page] -->|CustomEvent| B[Event Bus]
  B -->|CustomEvent| C[Cart]
  D[Shell] -->|Props / Attributes| A
  D -->|Props / Attributes| C
  E[Shared Store] <-->|subscribe| A
  E <-->|subscribe| C

Summary##

• Micro-Frontend 是前端的微服務架構。 每個功能區塊獨立開發、測試、部署，解決大型團隊的協作瓶頸。
• 三種主流整合模式： iframe（最隔離）、Web Components（瀏覽器原生）、Module Federation（最佳效能與開發體驗）。
• 選擇標準看團隊，不看技術。 如果團隊都在 webpack 生態系，Module Federation 是首選。
• 通訊越少越好。 如果兩個 micro-frontend 需要頻繁溝通，代表邊界切錯了。
• 不要為了架構而架構。 小團隊用 monolith，大團隊才需要 Micro-Frontend。