常見的微前端解決方案

要實施微前端有很多解決方案，目前有幾種主流的方法大致上會有幾種。

以 Application 層級來說

xhr/fetch javascript file to insert in script tag

說穿了就是直接插入 script tag 把 JavaScript 運行起來，注入 global 之中。或是引用單例註冊對象針對行為、元件、模組、資源來供給註冊。

這種方法可簡單可複雜，好壞上下限非常巨大。

module-federation

使用 webpack 或 vite 提供的 module-federation-plugin 來註冊，它屬於前一種方法的延伸，但提供了完整的解決方案和易懂的操作模式。

但因為吃到了打包體系，webpack 和 vite 並沒有完全通用，進而導致運作會發生異常。採用時必須讓打包工具一致化。

use micro frontend framework (single-spa, qiankun, wujie)

這是最省力的解決方案，事實上這也是基於前面兩種所做的更高階的方法，把維護問題交給套件方。

但同時你失去了微調能力，很多時候在微前端實作在乎的並不是單純實作出微前端，而是各種細膩的優化與調控。

以 Component 層級來說

iframe

這是最古老最穩定的方法，副作用也是最少的，最不容易發生污染的解決方案。

但這方法的缺點卻也是最多的。
溝通麻煩，需要透過 Dom 取得後由外而內，卻不容易由內而外溝通，跨域時更甚至需要依靠伺服器端來進行溝通。
這方法也同時非常吃資源，它會消耗非常驚人的記憶體和運算資源，沒辦法進行大量掛載。
另外就是 SEO 的扣分，它可能比 CSR 造成的影響更大。

WebComponent

原生的組件化解決方案，對於各種環境與架構相容性較好。
實體生成與註冊不強制順序，更容易額外封裝。
具備 Shadow DOM 功能，可以隔離 document 的作用域。

優點很多，缺點也不少。
對 SSR 不友善，需要搭配 SSI 相關技術。
拓展功能不如框架的 Component 好用，需要基於 DOM 元件的基礎延伸。
Shadow DOM 也是一把雙面刃，徹底隔離也帶來一些麻煩，後面會額外探討。

Frontend Framework Component

使用框架的 Component 可以說是幾乎沒有學習成本，使用最直覺。
資料傳遞可以直接依附框架的機制溝通，處理起來更加容易。
建構時也可以大量縮小程式體積，有效降低總程式碼的大小，盡可能重複利用。
對應的 SSR 方案整合度高，容易被實作。

但對於這種解決方案，也有致命問題。
微前端應用被綁定在特定的框架、版本上，當要升版和整合時很容易因為版本不一致損壞。
因為溝通變得容易，元件和元件在開發上容易不自覺提高耦合度，採用很多不易反查的手法。
使用上會有種犧牲一些微前端的好處來換取架構上與撰寫上的便利，但又有點本末倒置，甚至有種不如別用微前端好的感覺。

常見的微前端框架

single-spa

這是當前最主流的微前端框架，基於 WebComponent 延展應用程式，對於目前各大主流框架都提供良好的解決方案。

qiankun（乾坤）

由螞蟻金服(Ant)團隊基於 single-spa 拓展開發的框架，更進一步封裝，使其更加貼合實際應用場景。

wujie（無界）

基於 WebComponent + iframe 延展的微前端框架，主打簡單易懂。