什麼是微前端？

大多數開發人員都聽說過微服務架構，但微前端是一個較不為人知的術語。顧名思義，微前端的概念與微服務相似。它試圖解決與單體式應用程式相同的許多問題。它們太大、難以合作，也難以改變。讓新人加入工作，可能會帶來痛苦。此外，如果多個團隊正在處理應用程式的不同部分，他們將需要互相協調所有變更。

微服務可協助您將後端拆分為更獨立的服務。相同的方法可以用來將單頁應用程式（SPAs）分割為較小的應用程式，另外還需要一個“orchestrator”，可以將不同的零件裝回，讓使用者仍然遇到 SPA 行為。

微前端架構有哪些替代方案？

當然，還有其他方法可以處理大型應用程式的一些不想要的方面，例如將部分程式碼分成自己的 npm 套件。這可以解決部分問題，例如 Repo 太大。例如，在 Angular 中，您也可以將程式碼分開到可延遲載入的模組中。這可以允許應用程式在某種程度上進行垂直分割。但它也有缺點，像是在更新其中一個相依性時，必須建立頂級專案。此外，開發人員體驗也不那麼好。使用任何類型的框架時，最好將所有內容升級到相同版本，但這是一項巨大的承諾，沒有人會興奮不已。您也可以選擇透過 iframe 將多個應用程式結合在一起。它使它們獨立，但我認為可能過於獨立，因為應用程式間通訊是一個問題，共享程式碼、風格等也是問題。 

微前端救援？

微前端是這兩種方法的組合。與 SPA 相比，每個微前端都是一個獨立的應用程式。它不是編譯至 index.html 與連結的指令碼和樣式檔案，而是編譯至 JavaScript 模組。代碼並非主要應用程式的 iframe，而是定義當 URL 與某些模式相符時，模組就會延遲載入並放置在特定位置。有鑑於此，我們在同一頁上可以有多個應用程式相互連結。

因此，微前端無需處理應用程式配置和基本 CSS 規則，這些規則只能在主應用程式中處理。同樣有益的一點是，如果我有多個微前端使用相同版本的 React，我可以讓他們分享 React 模組。不必為每個微前端分別下載。JS 模組有不同版本也沒問題。

微前端的主要擔憂是確保其風格不會溢流到應用程式的其他部分。幸運的是，最常用的 UI 框架有工具可以輕鬆處理。

微前端架構的模具

編寫自己的程式碼來載入微前端應用程式，將是一項相當大的任務。幸運的是，有多個架構可以處理調度，並提供工具將最常用架構寫入的應用程式轉換為微前端格式。

在 Pure，我們選用了 single-spa。我們發現的主要好處是容易理解、為 JS 框架提供廣泛的支援，並有詳細的文件記錄。此外，single-spa 提供多種類型的微前端，每種前端都適合稍有不同的工作。

目前，我們只使用“應用程式”類型，因為從 SPA 移至微前端最容易使用。其他類型也需要更詳細的微前端架構。此外，single-spa 作者建議將“應用程式”作為預設值。

使用 single-SPA 架構打造微前端

目前，我們正使用 single-SPA 來搭配一個更大的應用程式，這些應用程式目前大約包含五個微前端。有時，與主要應用程式開發團隊相比，不同的團隊正在努力開發這些微前端。幸運的是，從改用微端沿以來的六個月內，我們沒有報告任何問題。我們也非常高興，主要應用程式不像以前那樣誇張，可以更輕鬆地升級。此外，在增加新功能時，我們不必擔心副作用，因為通常使用微前端。在不久的將來，我們希望分割 Pure 開發的其他大型應用程式的前端，因為這些應用程式的優勢可能也相當重要。如果您面臨與我們相同的問題，我們建議您試試看微前端。