微前端也是微服務

其實微前端跟微服務超級像，很多時候模組與模組之間的關聯性就是這樣被建立出來的。我剛開始還沒意識到這點，常常網路上翻來覆去都沒有微前端的資訊，直到某天我意識到，其實微前端就是「存放 UI 的微服務」，這下我就懂了。

模組分類

在模組分類上基本上有兩大流派，「按元件功能分類」和「按商業邏輯分類」，但是在微服務上這並不是絕對的。以單個獨立服務來說，可以是 Database、Message Queue、API Service、Renderer Service... 等等。但也有可能依照商業邏輯的不同而建立 Service，就好比是有負責登入權限的 Auth Service，也有負責購買功能的 Billing Service，也可以是某個核心功能的外掛 Plugin Service。諸如此類的分類方式都可以是微服務的核心設計之一，

溝通橋樑

在微服務中，每一個服務都是一個獨立自治的環境，不會任意發生溝通。當有服務與服務之間需要溝通時，都是採用網路協定進行溝通，諸如俗稱的「API 串接」。當然回歸底層就是靠網路協定，諸如 TCP/IP, Socket, MQTT... 等等這類的協定。所以溝通本身是需要被規範的，需要被定義的。

對微前端來說有什麼意義

我並不是想特別強調微服務，而是先用微服務的角度來看切分和溝通。但做了一陣子微前端就會發現，單純用微服務看其實相當不適用於微前端。微前端沒有網路溝通的時間成本，卻有加載資源的時間成本。微前端沒有儲存空間議題、沒有負載平衡議題、沒有資源競爭議題、運行服務崩潰議題，但卻有綑綁資源大小議題、背景處理服務議題。所以微前端面臨的世界和後端截然不同，專注的點也會不同。

以微服務的 Database 來說，因爲前端本身就沒有儲存空間的議題，無論存了什麼都是放在瀏覽器上，能存了就好。沒有負載平衡、資源競爭、橫向拓展等等要面對的難題，所以把資料庫作為一個微前端服務是多餘的，沒有解決任何議題，頂多是個有附帶邏輯的操作行為，在沒有商業邏輯支撐的微前端是沒有意義的，不如就包成 Library 發布，靠 module federation 進行共用。

了解微服務確實可以幫助設計微前端，但絕對不能認為解決方案可以一致性去使用解決方案。