過去十多年間，前端開發大幅演進。現今我們所開發的網頁應用程式，必須要能快速載入、在不同裝置上運行，還得迅速回應使用者的互動。可想而知，前端開發需要投入很多時間構思、並鉅細靡遺地處理網站細節。
當專案規模還小、只需跟少數幾名開發人員合作時，要打造一個好的網頁應用程式非常單純。但如果你的公司擁有的是一個大型網站，而且想持續改良並增添新功能，單單一個團隊馬上就會應付不過來了。這正是微前端架構能發揮優勢的地方：在微前端架構下，網頁應用程式被拆分成多個區塊 ，使多個團隊都能獨立作業。
微前端不是一個實際技術，而是一種新的組織及架構方法，自然也不是指某一種特定的框架。傳統開發方式時常採用水平架構, 例如整個專案有一個前端團隊，搭配一個以上的後端團隊或 UI 設計團隊。如果專案規模不大，每個任務都有專人負責，整個案子沒幾個人，這樣運作起來會很順暢，但若是大型專案，複雜度增加，任何系統的更動可能會出其不意地影響到其他部分，加上團隊人員眾多，內部的討論變得越來越麻煩，動不動就要跨團隊、跨部門溝通。
微前端架構提倡的則是另一種做法：將應用程式垂直拆解, 每個區塊交給一個專責團隊負責, 一條龍地包含從資料庫連接到使用者介面的開發。不同團隊的前端單元會在客戶端的瀏覽器內整合, 構成最終的頁面。
常見的微前端架構
微前端的其中一個好處是，每個團隊都可以自由採用符合其需求的技術，前提是所有團隊都得在高階架構上達成一致。舉例來說，我們的目標是開發靜態網頁、只透過超連結整合，還是要打造一個高度動態、整合較緊密的單頁面應用程式？在這種時候，你應該找來所有團隊一起做決定。下圖列出 6 種不同的架構。
我們將由上往下逐介紹。
用超連結串起的頁面
這是最簡單的架構。各團隊的頁面都是完全透過伺服器渲染的 HTML文件，按下網站的超連結就會重新載入新內容。不管你是在同一團隊內切換網頁，或跨團隊進行頁面瀏覽，這都屬於硬導覽。
這種架構的優點正是在於它簡單：無須中央基礎設施或共用的程式碼，偵錯非常直覺，而新的開發人員接手時也能馬上進入狀況。但從使用者體驗來說，超連結仍有改善的空間。
伺服器路由
這方法和超連結很類似，差異在於所有請求都會經過共享的網路伺服器或反向代理伺服器。這個伺服器會擺在各團隊的應用程式前面，並藉由一組路由規範來決定新進來的請求該交由哪一組團隊處理。路由規則通常是以跟團隊有關的網址前綴詞作為依據。若要回顧，可參閱本書第 3 章。
連結的 SPA
若要提升使用者體驗，並對使用者的輸入更快做出回應，團隊可以考慮捨棄伺服器端生成的靜態網頁，改而把自家的頁面實作成在客戶端渲染的單頁應用程式 (SPA)。這麼一來，只要點擊的連結是導向該團隊的頁面，都會變成速度快的軟導覽，但跨團隊的頁面切換依舊是硬導覽。
技術上來說，若一個團隊內部採用 SPA 架構，可以單純視為是實作細節。只要外部連結到該團隊的特定頁面都能作用，團隊都可以自行決定如何改變自家的內部架構。但等我們後面談到更進階的架構與更合適的整合技巧時，互相連結的頁面跟互相連結的 SPA 有何差異，就會變成一大關鍵了。
連結的通用 SPA
所有團隊也可考慮採用通用渲染──使用者首次請求的 HTML 會在伺服器端產生，使得首次頁面載入體驗相當快。應用程式在這之後就會表現得像 SPA，視需要逐步更新使用者介面。
從單一團隊的角度來看，這設定起來比較複雜，需要額外的開發技能。但就架構角度來看， 這個做法就和其他『相互連結』的架構無異。團隊間的契約仍然是一組共享的 URL 格式，跨團隊轉頁時也會重新載入頁面。但若這個架構實作得宜，頁面重新載入的順暢度應該會優於『連結的 SPA』架構，因為後者重載頁面時得在瀏覽器執行許多 JavaScript，才能讓內容顯現在使用者眼前。本書第 8 章便探討了通用渲染以及其優點、挑戰。
統一 SPA
統一 SPA 是指由多個 SPA 集結成一個單頁面應用程式，本書第 7 章介紹了這個概念。參與專案的所有團隊都必須以 SPA 形式來開發應用程式，而最上層會有一個父程式 (又稱為 app shell) 來統整這些 SPA。app shell 通常不渲染任何使用者介面，其職責在於監聽瀏覽器網址列是否有變更，然後視需要將控制權從現有的 SPA 轉給另一個 SPA。在這個架構底下，所有轉頁都會是軟導覽形式，使用者介面會變得更靈敏、更像真正的應用程式。然而，app shell 是不屬於任何團隊的一塊核心程式碼，其存在會帶來不低的耦合及複雜度。
統一通用 SPA
若你採用統一 SPA 模式，再給它加上通用渲染的話，就解鎖了所謂的『統一通用 SPA』。在這個模式下，每組團隊開發的 SPA 都得具備通用渲染能力，而核心應用程式 (app shell) 同樣得如此，並能同時在伺服器端跟客戶端運作。這架構集優點於一身，但非常有挑戰性，複雜度也是最高的。
複雜度比較
你選擇的架構與整合程度都會影響到你的專案複雜度。複雜度可以反映在不同的面向：
●讓專案起步所需的初步基礎設施。
●需要維護的可動組件數量，比如服務或 artifact (專案資產檔案)。
●耦合數量：那些變更會需要動用超過一個團隊？
●開發人員技能等級：新的開發人員需要掌握那些概念？
●偵錯：有臭蟲發生時，能否很輕易找到負責的團隊？
下圖將各個架構依照複雜度分群。由左到右，從非常簡單到非常複雜做排序，共分為四個群組。這當然只是大方向指引，挑選架構的關鍵，取決於團隊的經驗以及使用案例。根據經驗法則，應該總是選擇你能力範圍內、最為簡單的架構。採用一統的單頁面應用程式，沒有生硬的頁面切換固然是很好，但額外下功夫去做這樣子的開發，以及後續維護作業，是否符合效益？
也可採用非同質架構
通常我們習慣讓所有團隊都使用相同架構，但你其實也可以混用不同的東西，來打造一套非同質架構。對於開發登陸頁面的團隊來說，載入速度要快，所以用超連結串起頁面可能就已經足夠。但若要打造無縫的瀏覽體驗，你便需要打造一個統一 SPA，把負責產品清單的團隊、以及管理產品頁的團隊整合起來。這些架構可以平行運作，有的團隊只用超連結，其他團隊則共享一個 app shell 來實作統一 SPA。這樣一來，你就只會在有必要的地方增加複雜度。
但使用非同質架構也有一些缺點：
●新團隊沒辦法直接採用某個架構。各團隊必須事先就各自的使用案例分析並討論 (但這有時不一定是缺點)。
●整合不同團隊的頁面區塊，可能會變得更困難。團隊必須把他們的微前端個體包裝成目標頁面可嵌入的形式。
小結
最後要採用哪種架構進行開發，會取決於你的網頁用途，相關內容會在另一篇文章繼續討論。或者你也可以直接參考繁體中文唯一的微前端專書《決戰！微前端架構 Micro Frontends：新一代可擴展的網頁開發模式，實現各種框架的無縫整合與溝通》一書。
參考資料：
1. Which Technique/Architecture is right for my Project?(https://www.techolac.com/business/which-technique-architecture-is-right-for-my-project)
2.《決戰！微前端架構 Micro Frontends：新一代可擴展的網頁開發模式，實現各種框架的無縫整合與溝通》, 旗標科技出版。
