Florian Rappl 原作，授權 New Frontend 翻譯。
微前端是前端開發最具爭議的話題之一。值得嗎？真的需要切分應用嗎？真的需現在就轉向微前端嗎？這是不是又一個諮詢公司為了多賺錢發明出來的概念？
儘管人們對微前端多有誤解，我們不能否認微前端日益流行這一事實。讓我們看下誰在使用微前端，到底為什麼用微前端，還有一些方便上手的現成解決方案。
微前端到底是什麼
微前端試圖把拆分大型後端系統的一些益處引入前端。
最大的問題在於部分總是被整體使用。
後端系統從不被整體使用，而前端直接為使用者體驗（UX）負責。
應對這一問題有很多方式。最簡單的方式是把現有的 API 資料交換模型換成 HTML 輸出，只需一個超連結就可以從一個服務（檢視）轉到另一個服務（檢視）。缺點是在大多數使用場景下，這麼做肯定無法滿足使用者體驗方面的需求。
顯然，我們需要更復雜的方法，將單獨開發的使用者介面小元件組合成一致的前端介面。這可以算是分散式 web 應用演進的下一步。
微前端和元件、模組的關係是什麼？這是一個好問題。這些概念都意味著通過拆分單元的方式讓程式碼更易複用，更易歸責。唯一的差別是層次不同：
- 元件構成介面庫。
- 模組構成相應的執行時。
- 包構成依賴關係。
- 微前端構成呈現的應用。
因此，如果把微前端比作器官，那麼包就相當於細胞，模組就相當於分子，元件就相當於原子。
為什麼要用微前端
採用微前端的原因有許多種，經常主要是為了技術本身，不過，理想情況下，採用微前端是基於真實業務場景，或是出於改善使用者體驗的需要。
微前端方案的核心在於追求以下特性：
- 前端各部分可以單獨開發、測試、部署。
- 前端各部分的增加、移除、替換無需重新構建。
- 前端各部分可以採用不同的技術。
因此，微前端的精髓在於解藕。應用達到特定規模後，微前端開始變得有意義。其中一個好處是更多潛在的團隊劃分可能性，包括組建更小的全棧團隊。
在滿足以下一項或多項條件時，微前端值得考慮：
- 多個團隊貢獻前端程式碼
- 面向特定使用者或使用者組啟用、關閉、推出前端的某一部分
- 允許外部開發者擴充套件使用者介面
- 使用者介面每天或每週都會加入新特性，同時又不能影響系統的其他部分
- 在應用增長的情況下保持開發速度恆定
- 不同團隊能夠使用自己的工具
誰在用微前端
有越來越多的公司正在使用微前端，包括：
- DAZN
- Elsevier
- entando
- Fiverr
- Hello Fresh
- IKEA
- Bit.dev
- Microsoft
- Open Table
- OpenMRS
- Otto
- SAP
- Sixt
- Skyscanner
- smapiot
- Spotify
- Starbucks
- Thalia
- Zalando
- ZEISS
- …… 以及更多
這些公司使用微前端的具體方式各不相同，不過，使用微前端的意圖大同小異。
（上圖來自 Luca Mezzalira）
這個列表每天都在增長，從 ThoughtWorks、HLC 這樣的諮詢公司到 SalesPad、Apptio 這樣的 SaaS 提供商。但是很多傳統的公司也開始押注微前端。德國的隱形冠軍霍夫曼集團就是其中的一個例子。
霍夫曼集團是一個很好的例子，微前端不需要非常大的團隊，也不需要公司內部的資源。霍夫曼集團選擇微前端的原因正是因為它們要和多個服務提供商打交道。
微前端元件的例子
[Bit.dev] 平臺和營銷網站都是基於 React 元件構建，管理 React 元件是通過……Bit。
看看它們的頁面。懸停在不同元件上會顯示這些元件原本屬於哪個元件集。點選元件名可以檢視元件，甚至在你的專案中加入這一元件。
這個頁面是通過兩個元件集中的元件構建的，這兩個元件集對應 GitHub 上兩個不同的程式碼倉庫，[base-ui] (Bit.dev 頁面) 和 evangelist。
base-ui 元件集起到了設計系統的作用。evangelist 元件集中的元件（用於營銷頁面）使用了 base-ui 中的一些元件，以便在不同的微前端上保持統一的風格。
在這個例子中，Bit 既用於實現自主交付，也用於保持不同微前端的介面一致。
如何構建微前端
很不幸，這個有趣的問題只有一個含混的答案：就像微服務一樣，並不存在適用於所有人的單一方法，也沒有業界標準。
不同於微服務，微前端引入了基本性的差異，而不僅僅是實現細節上的差異。所以，我們需要區分微前端的使用範圍。一些服務端框架也允許客戶端複合（client-side composition），不過，相反的情況也是成立的。
客戶端框架
客戶端微前端框架有很多，有些也同時支援服務端渲染。
以下框架實現了微前端模式（或類似微前端的模式）：
服務端框架
服務端微前端框架也不少。有些不過是基於 express 的庫或框架，但另一些框架則需要依託於你的基礎設施。
以下框架實現了微前端模式（或類似微前端的模式）：
輔助庫
還有一些輔助庫提供了一些基礎設施，例如共用依賴、路由事件、組合不同的微前端及其生命週期。
下面是一個[處理共用依賴]的例子，利用了 import maps、chunk （webpack 內部使用的一個概念） 之類的機制。
下面這些庫有助於減少模板程式碼：
微前端調研
我希望以後基於社群資料重新梳理一下這部分的內容。但我需要你們幫忙提供資料。
我用 谷歌表單做了一份簡單的調查表，應該能在 5 分鐘之內填完。請幫忙擴散（比如通過 Twitter）。非常感謝！
調查到八月底截止，九月初會發表結果。
微前端的下一步
儘管有些人覺得微前端會集體轉向模組聚合（module federation）之類的輔助庫，大多數人仍將使用自研解決方案。好訊息是在許多框架下很容易編寫避開強供應商鎖定的程式碼。不管怎麼說，微前端缺少一個公共標準，方便在技術層面交換解決方案。
另外，目前微前端仍未被社群廣泛接受和採用。
儘管微前端模式變得流行，社群中仍有很多人心存疑慮。
有一個原因是微服務並沒有被視為面向特定場景的另一個工具，而是被視為設計後端時的一種最佳實踐和標準。顯然微服務不應該這麼用。因此，微前端也不應該被視為銀彈。
結語
微前端有許多現成的解決方案，許多專案也已經採用微前端，這是一個強烈的訊號：微前端已就緒！我建議在開始一個具有一定規模的生產環境專案前，先調研下各種模式和方案。
我希望你喜歡這篇文章！我希望知道你持哪一方的觀點及其原因。你喜歡微前端，可以容忍微前端，還是討厭微前端？
Photo by Ben Allan on Unsplash