微前端落地：Systemjs模塊化解決方案
如何實(shí)現(xiàn)多個(gè)應(yīng)用之間的資源共享？
之前比較多的處理方式是 npm 包形式抽離和引用，比如多個(gè)應(yīng)用項(xiàng)目之間，可能有某業(yè)務(wù)邏輯模塊或者其他是可復(fù)用的，便抽離出來以 npm 包的形式進(jìn)行管理和使用。但這樣卻帶來了以下幾個(gè)問題：
? 發(fā)布效率低下。如果需要迭代npm包內(nèi)的邏輯業(yè)務(wù)，需要先發(fā)布npm包之后，在每個(gè)使用了該 npm 包的應(yīng)用都更新一次 npm 包版本，再各自構(gòu)建發(fā)布一次，過程繁瑣。如果涉及到的應(yīng)用更多的話，花費(fèi)的人力和精力就更多了。
?多團(tuán)隊(duì)協(xié)作容易不規(guī)范。包含通用模塊的 npm 包作為共享資產(chǎn)，“每個(gè)人”擁有它，但在實(shí)踐中，這通常意味著沒有人擁有它。它很快就會(huì)充滿雜亂且風(fēng)格不一致的代碼，沒有明確的約定或技術(shù)愿景。
這些問題讓我們意識(shí)到，擴(kuò)展前端開發(fā)規(guī)模以便于多個(gè)團(tuán)隊(duì)可以同時(shí)開發(fā)一個(gè)大型且復(fù)雜的產(chǎn)品是一個(gè)重要但又棘手的難題。
因此，早在2016年，微前端概念誕生了。
什么是微前端？
微前端的概念
Micro Frontends: https://micro-frontends.org/ 官網(wǎng)定義了微前端概念：
Techniques, strategies andrecipes for building a modern web app with multiple teams that can shipfeatures independently.
從 Micro Frontends 官網(wǎng)可以了解到，微前端概念是從微服務(wù)概念擴(kuò)展而來的，摒棄大型單體方式，將前端整體分解為小而簡單的塊，這些塊可以獨(dú)立開發(fā)、測(cè)試和部署。同時(shí)仍然聚合為一個(gè)產(chǎn)品出現(xiàn)在客戶面前。可以理解微前端是一種將多個(gè)可獨(dú)立交付的小型前端應(yīng)用聚合為一個(gè)整體的架構(gòu)風(fēng)格。
值得留意的幾個(gè)點(diǎn)：
? 微前端不是一門具體的技術(shù)，而是整合了技術(shù)、策略和方法，可能會(huì)以腳手架、輔助插件和規(guī)范約束這種生態(tài)圈形式展示出來，是一種宏觀上的架構(gòu)。這種架構(gòu)目前有多種方案，都有利弊之處，但只要適用當(dāng)前業(yè)務(wù)場景的就是好方案。
? 微前端并沒有技術(shù)棧的約束。每一套微前端方案的設(shè)計(jì)，都是基于實(shí)際需求出發(fā)。如果是多團(tuán)隊(duì)統(tǒng)一使用了 react 技術(shù)棧，可能對(duì)微前端方案的跨技術(shù)棧使用并沒有要求；如果是多團(tuán)隊(duì)同時(shí)使用了 react 和 vue 技術(shù)棧，可能就對(duì)微前端的跨技術(shù)棧要求比較高。
微前端的使用場景
1. 拆分巨型應(yīng)用，使應(yīng)用變得更加可維護(hù)。
2. 兼容歷史應(yīng)用，實(shí)現(xiàn)增量開發(fā)。
微前端的優(yōu)勢(shì)
同步更新
對(duì)比了 npm 包方式抽離，讓我們意識(shí)到更新流程和效率的重要性。微前端由于是多個(gè)子應(yīng)用的聚合，如果多個(gè)業(yè)務(wù)應(yīng)用依賴同一個(gè)服務(wù)應(yīng)用的功能模塊，只需要更新服務(wù)應(yīng)用，其他業(yè)務(wù)應(yīng)用就可以立馬更新，從而縮短了更新流程和節(jié)約了更新成本。
增量升級(jí)
遷移是一項(xiàng)非常耗時(shí)且艱難的任務(wù)。比如有一個(gè)管理系統(tǒng)使用 AngularJS 開發(fā)維護(hù)已經(jīng)有三年時(shí)間，但是隨時(shí)間的推移和團(tuán)隊(duì)成員的變更，無論從開發(fā)成本還是用人需求上，AngularJS 已經(jīng)不能滿足要求，于是團(tuán)隊(duì)想要更新技術(shù)棧，想在其他框架中實(shí)現(xiàn)新的需求，但是現(xiàn)有項(xiàng)目怎么辦？直接遷移是不可能的，在新的框架中完全重寫也不太現(xiàn)實(shí)。
使用微前端架構(gòu)就可以解決問題，在保留原有項(xiàng)目的同時(shí)，可以完全使用新的框架開發(fā)新的需求，然后再使用微前端架構(gòu)將舊的項(xiàng)目和新的項(xiàng)目進(jìn)行整合。這樣既可以使產(chǎn)品得到更好的用戶體驗(yàn)，也可以使團(tuán)隊(duì)成員在技術(shù)上得到進(jìn)步，產(chǎn)品開發(fā)成本也降到的最低。
獨(dú)立部署與發(fā)布
在目前的單頁應(yīng)用架構(gòu)中，使用組件構(gòu)建用戶界面，應(yīng)用中的每個(gè)組件或功能開發(fā)完成或者 bug 修復(fù)完成后，每次都需要對(duì)整個(gè)產(chǎn)品重新進(jìn)行構(gòu)建和發(fā)布，任務(wù)耗時(shí)操作上也比較繁瑣。
在使用了微前端架構(gòu)后，可以將不能的功能模塊拆分成獨(dú)立的應(yīng)用，此時(shí)功能模塊就可以單獨(dú)構(gòu)建單獨(dú)發(fā)布了，構(gòu)建時(shí)間也會(huì)變得非常快，應(yīng)用發(fā)布后不需要更改其他內(nèi)容應(yīng)用就會(huì)自動(dòng)更新，這意味著你可以進(jìn)行頻繁地構(gòu)建發(fā)布操作了。
獨(dú)立團(tuán)隊(duì)決策
因?yàn)槲⑶岸藰?gòu)架與框架無關(guān)，當(dāng)一個(gè)應(yīng)用由多個(gè)團(tuán)隊(duì)進(jìn)行開發(fā)時(shí)，每個(gè)團(tuán)隊(duì)都可以使用自己擅長的技術(shù)棧進(jìn)行開發(fā)，也就是它允許適當(dāng)?shù)淖寛F(tuán)隊(duì)決策使用哪種技術(shù)，從而使團(tuán)隊(duì)協(xié)作變得不再僵硬。
微前端落地方案
自組織模式：通過約定進(jìn)行互調(diào)，但會(huì)遇到處理第三方依賴等問題。
基座模式：通過搭建基座、配置中心來管理子應(yīng)用。如基于 SIngle Spa 的偏通用的乾坤方案，也有基于本身團(tuán)隊(duì)業(yè)務(wù)量身定制的方案。
去中心模式：脫離基座模式，每個(gè)應(yīng)用之間都可以彼此分享資源。如基于 Webpack 5 Module Federation 實(shí)現(xiàn)的 EMP 微前端方案，可以實(shí)現(xiàn)多個(gè)應(yīng)用彼此共享資源分享。
其中，目前值得關(guān)注是去中心模式中的 EMP 微前端方案，既可以實(shí)現(xiàn)跨技術(shù)棧調(diào)用，又可以在相同技術(shù)棧的應(yīng)用間深度定制共享資源。如果剛開始調(diào)研微前端的話，可以先嘗試了解一下EMP微前端方案，或許會(huì)給你帶來不錯(cuò)的使用體驗(yàn)。
Systemjs 模塊化解決方案
Systemjs：https://github.com/systemjs/systemjs
在微前端架構(gòu)中，微應(yīng)用被打包為模塊，但瀏覽器不支持模塊化，需要使用 systemjs 實(shí)現(xiàn)瀏覽器中的模塊化。
systemjs 是一個(gè)用于實(shí)現(xiàn)模塊化的 JavaScript 庫，有屬于自己的模塊化規(guī)范。
在開發(fā)階段我們可以使用 ES 模塊規(guī)范，然后使用 webpack 將其轉(zhuǎn)換為 systemjs 支持的模塊。
案例：通過 webpack 將 react 應(yīng)用打包為 systemjs 模塊，在通過 systemjs 在瀏覽器中加載模塊。
npm install [email protected]@4.4.0 [email protected] [email protected]@babel/[email protected] @babel/[email protected] @babel/[email protected]@babel/[email protected] [email protected]
src/index.html
src/index.js
src/App.js
package.json
webpack.config.js
推薦閱讀：
云函數(shù) Todo 重構(gòu) + Vue 客戶端調(diào)用
拉新活動(dòng)必備——node + fc 部署海報(bào)生成服務(wù)
這是我的第 120 篇文章。
恭喜你又在前端道路上進(jìn)步了一點(diǎn)點(diǎn)。
點(diǎn)個(gè)“在看”和“贊”吧！