我是怎麼樣開始寫微前端？

在進入解決方案篇章前，先來說說我身上發生什麼事，為什麼會開始玩微前端？剛開始是進入公司後，CTO 想要推行微前端，我就必須了解這一塊相關知識。雖然一直都知道什麼是微前端，但我還真沒有實際實作過，但也很開心有這樣的機會，我開始碰了這條路。

原因

那可能就有人會好奇，為什麼公司會想要做微前端呢？

多框架並行迭代

第一個原因，公司有多個前端框架同時運行。原本使用 Vue 2.6，但公司其他產品線都使用 React，長遠來說，其實是需要統一使用的技術線來降低維護成本的。但要一口氣重構轉換框架是一件曠時費力，而且成本非常高昂的工作。所以規劃後決定用 Migrate 的方式逐步重構，而這種重構方式，卻沒辦法做到換框架。基於這樣的麻煩背景，微前端就是一個解決方案。

組態控制

第二個原因，我們很多產品在部分情境是要架在 Local 環境，所以依照需求不同的產品會有不同的功能組態，甚至可能因為很多即時的環境條件改變組態，如果全然依賴前端的 .env 作為判斷會需要重新打包，也沒辦法節約環境上基本的打包大小，甚至不容易管理落地核心的產品。如果使用微前端可以透過微服務組態來管理功能的引入，更容易達到在服務運行階段改變配置這件事，而不需要重新部署。

外部參與

第三個原因，上頭希望能將產品打造成一個可擴充可延展的產品，希望能給第二方或三方去追加功能。正因如此擴充性能是需要可以在客戶環境被動態掛載的，所以需要微前端這種極其動態自由的功能。

啟動

其實過程中我一直懷疑自己，也覺得不理解為什麼要採用這麼複雜的架構，明明就這麼簡單的業務要搞的這麼痛苦。但我覺得與其去糾結需要不需要，不如就用心體驗這門技術，

一開起從閱讀之前 POC 文件和專案，嘗試啟動和各種假說嘗試，我都抱持著一個試試看的心理在處理。剛接手第一個月可以說是相當崩潰，從建置 Webpack 的編譯環境，研究 ModuleFederation 的實現機制，這些都是坑山坑谷。但這些都還不是最崩潰的，最讓人崩潰的是要把一個 4 年以上的就專案進行重構成為前端架構，各種套件升級的 Error 一條條解決，舊專案既有問題的存續，還有許多不支援新版本的 API 等等問題。

當然在努力了兩到三個月，我完成基本的微前端架構雛形，著手導入開發，然後才知道... 事情並不是到這邊結束了，其實是下一波難題又迎面而來。這時我才意識到，架構(Architecture)本身就是一個框架(Framework)，如何管理好模組依賴？如何利用設計模式來規劃？如何讓團隊其他人理解？這些後續問題又漸漸浮上檯面...

這時我開始想到要框架化，依照 CTO 規劃的架構撰寫屬於我們團隊的「Framework」，這也開始一段艱辛的踩坑之路。