🎋 竹子日誌

微前端

#前端 #微前端 #架構

或許你聽過或是沒聽過以下詞彙，「微前端」、「微應用」、「前端微服務」。這些都是相同的東西，後面的文章我都會用「微前端」來稱呼。

你可能聽過微服務，這是已經行之有年的軟體開發架構風格，可以讓單一應用程式有自己的開發、部署、執行的生命週期，透過網路通道來達到相互溝通的能力。微服務是一個很好的切分單位，可以更容易讓更大的團隊溝組織通協作開發。

那微前端呢？

微前端就是把微服務的架構概念套來前端，將前端需要的模組分散在不同的服務上提供，而不是將所有資訊塞在同一個單體式架構中。所以可能在同一個前端應用程式中，有好幾個人一同開發與維護，並每個人都各自管理自己的部分，透過架構去讓程式溝通。

微前端要解決什麼問題？

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

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

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

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

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

微前端的優劣分析

既然產生這種架構必然會產生一些好處，也相對帶來一些壞處。

首先是好處：

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

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

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

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

當然，有好處就有壞處：

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

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

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

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

常見的為前端解決方案

要實施微前端有很多解決方案，目前有幾種主流的方法。

  • iframe

  • Frontend Framework Component

  • WebComponent

後面會針對這些方法做討論。

我怎麼看微前端？

剛開始我接手時，其實根本沒有成功建立任何的微前端，我是從頭建制這整個架構。而建構微前端的過程也是經歷許多坡折，但既然面對了就必須做好，作為公司主推的一項主軸技術，我就有責任把它處理好。

後面我會把這來龍去脈和心酸血淚逐條逐項分享，讓想嘗試這架構的你可以少走點彎路，其中也包含很多就算不是實作微前端也會遇到的前端基礎建設問題，讓我們各個擊破吧。

(二) 前期資訊查找與準備

當要採用一個技術前，第一步肯定是要做充分的資料收集與測試。我剛接手這個需求時，我第一步先把公司前端前手的研究進度重新閱覽一遍，並且嘗試建置 POC 專案，確認技術理解。

微前端第一個麻煩點，那就是溝通。

那微前端可以有哪些相互溝通的機制呢？如果不採用 iframe 為前提，其實 Web Site 所有的

留言