# 對微前端的美好想像 - Eric Lee

{%hackmd o8oUosN0QnqMSkF1_6kH7g %}

#### 📚 議程介紹

{%preview https://webconf.tw/agenda/12 %}

###### ▼▼▼ 開始筆記 ▼▼▼

Eric: 感謝大家聽我的 session，這邊放我的簡報不過這邊筆記好清楚
https://drive.google.com/file/d/1OOFRsSvIPIwy52XjPOszGSPHcPOsgGvt/view?usp=sharing

## Monolith 系統的擴展瓶頸

- Isolation 隔離性差： 模組間難以隔離，小改動就崩潰
- Indenpendent 難以獨立擴展：無法單獨擴展
- Long release cycle 發佈週期長：

## 核心概念：每個團隊管理自己的系統

- 每個團隊負責一個獨立的 service 如 user, payment
- 各自有該領域的 domain knowledge 與技術決策權
- 自主決定何時 release 、分配資源、選擇 tech stack
- 對前端而言，透過 rest api or graphl 串接服務

## 我們面臨的挑戰： 一個入口，多元宇宙

- 多重業務： 同時服務 B2C 與 B2B
- 複雜權限： 不同角色需不同 app 功能
- 開發瓶頸： 為各 use case 建獨立網站，成本極高

## iframe ： 微前端的早期嘗試

### Pros
- 真正獨立：每個 app 有自己的 runtime ，獨立 url
- 故障隔離： 單一 app crash 不影響其它部份
- 自主發佈： 團隊可以隨時部署更新，即時生效

### Cons

- 通訊困難： only depend on postMessage ，開發與 debug 體驗差
- 樣式難題： 內外樣式難協調，易出現非預期的 scrollbar
- 整合度低：難以實現無縫的整體使用體驗

## Why not npm install?

### npm install

- 發佈困難

### module federation

## Our choose: Webpack Module Federation

在 runtime 共享程式碼，實現真正的獨立部署

> 像在高速行駛的車上換輪胎，發新版本不用讓整台車回廠

**Key Feature**: 不只共享 app ，還可以共享函式庫 (e.g. React)，避免使用者重覆下載

## 理想中的動態架構
以使用者權限動態載入微前端，實現靈活、安全的應用組合。
## 這樣我們解決了

- ownership: 明確分工與 code owner ，共用 code template ，最大化自由度
- 獨立部署： 各組依據 release cycle 獨立部署，實現並行開發
- 效能： 僅載入權限所需App實現懶加載

## 痛點一： 依賴地獄

### Problem 1: 共享依賴的代價

Host app 需要關掉 tree shaking ，導致初始載入需要載入完整的 React, MUI, Sentry...

結果： 使用者看到了漫長的白畫面

不關的話，你的其它的 app 可能會發生沒有 `useEffect` 可用的情況

之前使用者要花12秒才能看到畫面

### Problem 2：更新的惡夢

更新共享套件需要所有團隊協調 Sprint
真實案例： 我們光是更新MUI與React版本就花了一整年

## 痛點二： CSS 污染與盲人摸象般的除錯

### CSS Conflics
CSS 會互相干擾　

### Debugging Nightmare

所有人打包出來的檔案都叫 `remoteEntry.js` ，在 Sentry 裡根本看不出來

> [name=DanSnow] 求在這邊加入 spider man 的梗圖

Module federation 是 webpack 發明的，很慢

分散式的自由也帶來分散式的混亂

## 一個重置的契機： B2C 官網遷移計劃

去年有個契機，轉到負責B2C的組，但同樣有分散式架構的挑戰

Eric: 我以為我逃離了 micro frontend 結果沒有

TL;DR: 轉到另一個組，結果那個組有 3 個 repo ：
- 低維護性： 一堆 custom code ，難以理解
- 重複依賴： 一個 button 元件有 5 個版本
- 漫長的建置： production build 要 30m ，而且常失敗

我們曾經七個人半夜兩點看著他 build 了半小時，最後一刻告訴你 memory 不足

## 新的藍圖： Turborepo + pnpm Monorepo


- 一個 repo 包含多個獨立的 Next.js app (每個對應一個 route)
-

## Monorepo 如何解決我們的痛點


Topic / Before / After
依賴更新 / 一年長跑，跨團隊協調 / `pnpm workspace` 統一版本，一鍵升級
共享邏輯 / 不確定誰在使用，難以追蹤 / 放在 common 資料夾， `ctrl + f` 就可以找到所有引用
獨立部署 / 具備，但流程分散 / 仍有，但 Turborepo 的 caching 加速 cicd

假如不知道什麼是 monorepo 推薦可以看這篇 [為什麼前端工程越來越愛使用 Monorepo 架構](https://medium.com/hannah-lin/%E7%82%BA%E4%BB%80%E9%BA%BC%E5%89%8D%E7%AB%AF%E5%B7%A5%E7%A8%8B%E8%B6%8A%E4%BE%86%E8%B6%8A%E6%84%9B%E4%BD%BF%E7%94%A8-monorepo-%E6%9E%B6%E6%A7%8B-661afa90910a)

## 對使用者而言，體驗無縫接軌

Vercel 也說他們是微前端，well 他們很有錢 XD

> 微前端往往不是單純的技術考量，而是「組職管理」的考量

有人問我要學微前端嗎？我覺得不一定，他是解決特定規模問題的手段。你要先了解適合的場景，解決的痛點，會牽涉到公司政治面的事情。這樣會比單純學會技術更重要。

---

會後問的一些問題與講者的回答分享

> 關於第二個案例中提到使用了多個 Next.js 的 application 來提供前端，這是如何運作的？

簡單來說，一個頁面就是一個 Next.js 的 application ，並且透過 nginx 的設定在不同的頁面導向不同的 Next.js 的 application

> 使用 monorepo 還是沒有解決需要協調不同團隊要一起升級的問題，為什麼在第二個案例中就解決了？

因為原本是不同的 repo 的架構下，其它團隊的看到你來動這個專案的會覺得你不是這個 code 的 owner 為什麼來動，但在 monorepo 下，因為大家都在同一個 repo 下，這個「心理的防線」減少了很多，問題其實還是存在，只是比較好協調 + 可以直接跑去改別人的 code 了

---

( ੭ ̇ᗜ ̇ )੭ 聊天室 ( ੭ ̇ᗜ ̇ )੭
在其他議程～想聽這場！許願共筆～～～

↑ 這是什麼增加共筆參與率的咒語嗎
>霸偷惹
>求🥹

一個人「共」筆很累…

有人來了，超感謝

謝天謝地空調終於關掉了，一直震動根本聽不到講者在說什麼。
聲音清楚多了

打包name在webpack有個filename屬性可以設定，就不會大家都叫remoteEntry.js
>感謝，那我要回去問問為何不改這個名字了哈哈

為什麼我的共筆常常斷線啊
>你不是一個人

我的照片是 heic 格式的，沒辦法上傳 😢