什麼是微前端架構? 為什麼要用微前端架構?
2024年5月27日
近幾年前端界,有個叫「微前端」的架構模式越來越流行。然而,什麼是微前端? 前端前面加的這個「微」代表什麼? 這種架構方式有什麼好處? 又有什麼潛在問題?
什麼是微前端?
微前端是一種目前業界相當流行的前端架構,這個架構模式的重點是「微」,而這個「微」是借鏡於微服務 (micro-service) 的架構模式。就像是微服務會把原本單體 (monolith) 拆成多個微小的服務,微前端也是採用類似的形式。
想像一下,今天有一個電商網站,最基本需要有商品瀏覽頁面、下單的訂單頁面、付款的金流頁面,以及出問題時的客服頁面。如果再更複雜一點,以商品來說,可以進一步展開商品細節頁;以客服來說,可能進一步有客服工單、客服真人諮詢等不同頁面。
在微前端架構下,這些都會是不同的前端應用程式,在不同的程式碼庫 (或者用 monorepo 的話,會是底下不同的子程式碼庫)。也如同微服務架構,微前端架構下的不同前端應用,可以用完全不同的技術棧。
例如客服工單頁可以用 React 來寫、客服即時聊天可以用 Vue 來寫,然後購物車可以用 Svelte 來寫 (這邊只是舉例,事實上目前多數微前端多半仍會選同樣的技術棧,因為若有共用的統一程式碼,只需用做一種框架的共用套件即可)。
上面這樣講起來可能有一點抽象,下面讓我們用具體的例子來說明,微前端架構在實務中的應用會是什麼樣。Amazon 底下的 AWS 是許多人都會用的服務,而 AWS 的操作介面正是以微前端架構來設計。在《Micro-frontend Architectures on AWS》一文中 AWS 團隊談到。
![image](https://explainthis.s3-ap-northeast-1.amazonaws.com/617ffc7c60454f0f92283023e16df78a.jpg)
在轉換成微前端架構之前,整體的架構會是一個單體的前端,搭配多個微服務。轉換成微前端架構後,則會是有一個主應用 (Parent Frontend),然後搭配多個子應用,例如個人資訊頁 (Profile Frontend)、帳單頁 (Billing Frontend)等,然後個人資訊頁就會直接對應到個人資訊頁的後端服務,同樣地帳單頁前端會對應到帳單頁後端的服務。 然而,相信這時你可能腦中會出現一些問題,例如「為什麼要這樣做?」、「拆成微前端的架構形式有什麼好處?」
在 E+ 的主題文中,我們將進一步討論這些問題,也同時會談微前端架構的設計原則、微前端架構的生命週期等。如果你想更進一步了解微前端主題,歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)。