微前端系列（二）

微前端要解決什麼問題？

會出現一種架構，代表背後就有一個要解決的問題。通常有以下幾種問題時，都可以考量導入微前端來解決當前架構問題。

既然產生這種架構必然會產生一些好處，也相對帶來一些壞處，做個微前端的優劣分析。

首先是好處：

• 所有架構各自為政，也可以輕易插拔這些服務元件，首先是解耦。就算特定應用有破壞性損壞，也可以大幅降低對整個應用產生的影響，最壞的情況就是一個微應用為單位崩潰，而不會導致整個應用架構崩潰。

• 再來就是應付大型團隊可以很好的去拆分職責，每個拆出去的 Repository 都可以獨立運行，選用自己想要的技術，並且各自為政不影響運行。

• 因為是單一功能部署，所以 CI/CD 的運行更快完成。

• 因為每一個功能都是基於被拆分的專案去開發，所以沒有超大型專案的維護壓力，只有各自小專案的規模。這樣開發節奏更快速，也可以承受更多工程師同時進行功能開發。

當然，有好處就有壞處：

• 載入的 Application 因為都拆分好幾塊，所以基本的 Bundle Size 比較大

• 功能操作限制多，不能操作 Browser Single State，否則狀態會同步異常，所以需要比較完善的團隊規範

• 使用的函式庫或框架限制多，不能任意選用套件

• 跨微前端溝通方式複雜且麻煩

那到底什麼樣的情境會需要使用微前端呢？

• 當單一前端專案越來越巨大，已經影響編譯時間與開發效率。

• 單一前端應用需要跨部門多個工程師共同維護，同一個產品已經很進行版本管理。

• 單一產品需要整合多種框架或多種版本共存迭代。

• 有大量需要多專案共用的業務與介面需要外放提供時。