微前端的現狀和趨勢

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），不過，相反的狀況也是成立的。

客戶端框架

客戶端微前端框架有不少，有些也同時支持服務端渲染。

如下框架實現了微前端模式（或相似微前端的模式）：

• Piral
• Open Components
• qiankun
• Luigi
• Frint.js

服務端框架

服務端微前端框架也很多。有些不過是基於 express 的庫或框架，但另外一些框架則須要依託於你的基礎設施。

如下框架實現了微前端模式（或相似微前端的模式）：

• Mosaic
• PuzzleJs
• Podium
• Micromono

輔助庫

還有一些輔助庫提供了一些基礎設施，例如共用依賴、路由事件、組合不一樣的微前端及其生命週期。

下面是一個[處理共用依賴]的例子，利用了 import maps、chunk （webpack 內部使用的一個概念） 之類的機制。

下面這些庫有助於減小模板代碼：

• Module Federation
• Siteless
• Single SPA
• Postal.js
• EventBus

微前端調研

我但願之後基於社區數據從新梳理一下這部分的內容。但我須要大家幫忙提供數據。

我用 谷歌表單作了一份簡單的調查表，應該能在 5 分鐘以內填完。請幫忙擴散（好比經過 Twitter）。很是感謝！

調查到八月底截止，九月初會發表結果。

微前端的下一步

儘管有些人以爲微前端會集體轉向模塊聚合（module federation）之類的輔助庫，大多數人仍將使用自研解決方案。好消息是在許多框架下很容易編寫避開強供應商鎖定的代碼。無論怎麼說，微前端缺乏一個公共標準，方便在技術層面交換解決方案。

另外，目前微前端仍未被社區普遍接受和採用。

儘管微前端模式變得流行，社區中仍有不少人心存疑慮。

有一個緣由是微服務並無被視爲面向特定場景的另外一個工具，而是被視爲設計後端時的一種最佳實踐和標準。顯然微服務不該該這麼用。所以，微前端也不應該被視爲銀彈。

結語

微前端有許多現成的解決方案，許多項目也已經採用微前端，這是一個強烈的信號：微前端已就緒！我建議在開始一個具備必定規模的生產環境項目前，先調研下各類模式和方案。

我但願你喜歡這篇文章！我但願知道你持哪一方的觀點及其緣由。你喜歡微前端，能夠容忍微前端，仍是討厭微前端？

Photo by Ben Allan on Unsplash

參考

• Building a UI Component Design System
• 6 Patterns for Microfrontends
• How to Publish React Components