前端微應用：前端大應用拆分爲多個小應用(?前端 nginx?)

時間 2019-11-24

標籤前端應用拆分多個 nginx 欄目 Nginx 简体版

原文原文鏈接

原文：www.yuque.com/xiezhongfu/…javascript

single-spa 框架你值得研究，源碼也比較簡單：www.yuque.com/xiezhongfu/…html

到底要不要微前端改造：mp.weixin.qq.com/s/ndNzkf1Gv…前端

隔離不一樣時期的代碼： 你有一個大型單頁面應用程序（SPA），參與開發的人來來每每比較多，多個迭代後業務代碼的差別比較明顯，應用的維護的成本比較高。
多個 spa 應用在一個上層 spa 中運行： 多個小 SPA 應用獨立運行太浪費，合在一塊兒給打包和編譯帶來風險(一個應用出現問題致使整個前端應用運轉不起來)。
三大框架共存於一個應用： 能夠實現 react, vue, angular 共存在一個應用裏嗎？好比你前端寫了好多 vue 組件，你想直接用在 react 體系裏怎麼辦呢？single-spa 框架了解下：www.yuque.com/xiezhongfu/…vue

天下大事合久必分。除了能夠使用ES2015模塊，webpack和npm對代碼進行模塊化，還能夠引入新的獨立SPA，每一個SPA獨立開發或部署——這就是在前端成功引入了面向服務的架構(SOA)。java

?前端 nginx?

react 應用中，router 能夠分發到不一樣的頁面。前端 historty 也能夠作到分發到不一樣的子應用。
這種技術方案其實對後端同窗來說已經很常見了，好比 nginx。react

面向服務的架構

面向服務的架構基本概念是服務，服務是一段孤立的代碼，只能經過 API 進行交互，服務能夠獨立開發/部署，這些服務之間是隔離的，是獨立的。服務的概念須要和共享庫的概念區分下。共享庫是編譯打包代碼綁在一塊兒，好比前端的 react庫等，升級共享庫必須重複發版到 npm 倉庫。webpack

前端爲何須要面向服務

業務場景舉例

前端業務模塊 A(後臺系統A)
前端業務模塊 B(後臺系統B)
前端業務模塊 C(後臺系統C)
......

爲了隔離不一樣時期，不一樣前端業務模塊，對接的不一樣後臺應用等，強烈想拆分開(代碼拆分)。面向服務的設計，公共代碼不是公共的依賴項，是經過獨立的服務，服務只是運行時加載。也正是由於是運行時加載，在應用啓動時若是同步加載過多的服務，性能可能會收到影響。在應用啓動後異步加載一些服務能夠減輕一些負擔。nginx

代碼拆分

當用戶訪問到不一樣路由時，加載對應的代碼。隨着路由和業務代碼的增長，路由可能會變得比較大，每一個路由對應的代碼也會變得比較大。所以不能只使用基於路由的代碼拆分。基於路徑的拆分很不錯(好比使用動態加載），那如何從單純的靜態加載變成有動態加載的呢？(好比多入口打包後動態加載後者獨立應用打包)git

singe-spa + 單倉庫

拆分完後基於 history 怎麼管理？singe-spa 源碼分析參見：www.yuque.com/xiezhongfu/…
單倉庫的實踐能夠參看 react 源碼倉庫對多個 package 的管理。把不一樣業務模塊放到不一樣的 package 管理。每個 package 是能夠單獨運行和部署的。web

關聯的技術

更多內容參考：mp.weixin.qq.com/s/6-yjR_CsH…

JS 沙箱和 CSS 隔離，是爲了讓子應用之間互不影響。
Html Entry 和 Config Entry，是關於如何註冊子應用信息。
按需加載、公共依賴加載和預加載，是關於性能的，這些很重要，不然雖然上了微前端，但性能嚴重降低，或者因爲升級引發線上故障，就得不償失了。
父子應用通信，顧名思義，無需解釋。
子應用嵌套和子應用並行是微前端的進階應用，在某些場景下會用到。

這是部分問題的實現原理。

首先子應用提供樣式、腳本等配置，有內聯也有外鏈。
先經過 SEMVER MAP 解決公共依賴不重複加載的問題，好比 antd、react 都只載一份。
而後經過 xhr 拉外鏈的樣式和腳本，實現按需加載。
樣式會合併成一份，經過 style 寫入到 DOM 結構，子應用 unmout 時刪除，以此作到 CSS 隔離。
腳本經過記錄和 diff window 變量上的屬性來取到子應用導出的生命週期方法，而後經過 eval + 基於 Proxy 實現的 Sandbox 實現 JS 沙箱。