微前端系列（七）

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

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

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

第二個原因，我們很多產品在部分情境是要架在 Local 環境，所以依照需求不同的產品會有不同的功能組態，甚至可能因為很多即時的環境條件改變組態，如果全然依賴前端的 .env 作為判斷會需要重新打包，也沒辦法節約環境上基本的打包大小，甚至不容易管理落地核心的產品。

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

或許有人覺得這些原因都不足夠說服他使用微前端，但我就是接下這份工作了，也開始弄了。