微前端的優化-模組切割

模組切割這件事幾乎是微前端的核心，所以怎麼切分模組就決定微前端能產生的價值。

為甚麼不要用元件切分？

前面提到，微前端就像是微服務，但又不能像微服務這樣進行切分，我們舉幾個元件來談談為什麼不要用元件區分。

• Database：通常資料庫代表的是儲存，但微前端中儲存空間本身不是什麼問題，更沒有查詢資料庫的分散效能議題，就算建立很多資料庫相關的服務也不會改善在前端的查詢效能。
• LoadBalancer：前端沒有什麼分流的議題，因為請求多寡去分服務不會在前端產效能差異，更沒有反向代理需求。
• MessageQueue：前端只有一個 JavaScript 的主線程核心，在 Event Loop 的機制上，不存在 Race Condition 的議題，如果只是要做功能擴展和解耦可以直接使用 EventEmitter 來作為 EventBus。

切分微前端到底要解決什麼問題？

微前端既然沒有請求堵塞問題，更沒有儲存障礙問題，最終遇到的效能瓶頸其實是要回歸微服務去管理，前端終究只能提供快取。問題又轉回來，微前端到底面臨什麼問題？當微前端要拆分最重要的問題是「管理」，隨著專案的複雜化和規模化勢必面臨切分，一但切分就會有昂貴的「載入成本」。模組切分並不是要切越細越好，只要進行切分載入就會要一個組裝成本，那勢必就會有一定的額外損失，仍然要依照基礎需要的結構去劃分，讓非必要的部分非同步化。

但依舊會有很多共用部分，好比 Library Package 相關的模組，或是把部分功能封裝成 Library 也是，最直觀的就是使用 ModuleFederation，但 MF 並不是萬靈丹，甚至可能是沈重的負擔，因為一般打包可以做到 Tree Shaking，但如果包成 MF，因為無法預期使用的模組，那就不能進行優化，此時只能將整包 Library 包一整包都獨立出來，那很可能很多用不到的部分就無差別的被包了出去。

這時 Packages 的管理在此時就需要很精密的策略，包含分包的顆粒度與依賴樹的版本，要讓版本共用效率最大化。此時你的 Packages 就不能包山包海，其實最好也能先使用一層打包去優化你真正要用到的模組，並往依賴樹內挑選必要有共用價值的和不要共用的做精選，特別是 UI 類型這種超巨大的 Library。