什麼是微前端架構? 為什麼要用微前端架構?

近幾年前端界，有個叫「微前端」的架構模式越來越流行。然而，什麼是微前端? 前端前面加的這個「微」代表什麼? 這種架構方式有什麼好處? 又有什麼潛在問題?

什麼是微前端?

微前端是一種目前業界相當流行的前端架構，這個架構模式的重點是「微」，而這個「微」是借鏡於微服務 (micro-service) 的架構模式。就像是微服務會把原本單體 (monolith) 拆成多個微小的服務，微前端也是採用類似的形式。

想像一下，今天有一個電商網站，最基本需要有商品瀏覽頁面、下單的訂單頁面、付款的金流頁面，以及出問題時的客服頁面。如果再更複雜一點，以商品來說，可以進一步展開商品細節頁；以客服來說，可能進一步有客服工單、客服真人諮詢等不同頁面。

在微前端架構下，這些都會是不同的前端應用程式，在不同的程式碼庫 (或者用 monorepo 的話，會是底下不同的子程式碼庫)。也如同微服務架構，微前端架構下的不同前端應用，可以用完全不同的技術棧。

例如客服工單頁可以用 React 來寫、客服即時聊天可以用 Vue 來寫，然後購物車可以用 Svelte 來寫 (這邊只是舉例，事實上目前多數微前端多半仍會選同樣的技術棧，因為若有共用的統一程式碼，只需用做一種框架的共用套件即可)。

上面這樣講起來可能有一點抽象，下面讓我們用具體的例子來說明，微前端架構在實務中的應用會是什麼樣。Amazon 底下的 AWS 是許多人都會用的服務，而 AWS 的操作介面正是以微前端架構來設計。在《Micro-frontend Architectures on AWS》一文中 AWS 團隊談到。

在轉換成微前端架構之前，整體的架構會是一個單體的前端，搭配多個微服務。轉換成微前端架構後，則會是有一個主應用 (Parent Frontend)，然後搭配多個子應用，例如個人資訊頁 (Profile Frontend)、帳單頁 (Billing Frontend)等，然後個人資訊頁就會直接對應到個人資訊頁的後端服務，同樣地帳單頁前端會對應到帳單頁後端的服務。 󠀠 然而，相信這時你可能腦中會出現一些問題，例如「為什麼要這樣做?」、「拆成微前端的架構形式有什麼好處?」

在 E+ 的主題文中，我們將進一步討論這些問題，也同時會談微前端架構的設計原則、微前端架構的生命週期等。如果你想更進一步了解微前端主題，歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)。