為什麼前端工程越來越愛使用 Monorepo 架構？

前端小智發表於2021-12-20
前端Mono架構
作者： HannahLin
來源：medium
有夢想，有乾貨，微信搜尋 【大遷世界】 關注這個在凌晨還在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收錄，有一線大廠面試完整考點、資料以及我的系列文章。

Monorepository (簡稱 Monorepo) 概念雖然有一段歷史了，但這個名詞卻是近幾年才變得如此熱門。自己公司也是這半年才匯入這個架構，再嚐到許多甜頭後想寫一篇來介紹它，希望多一點人認識此架構。這篇並不會有原始碼，而是從現有架構痛點開始 (Single Repo Monolith、Multi-repo)、為什麼要用 Monorepo 等等。

現有架構遇到了什麼問題 ?

20 年前的前端相當單純，但在這 6 ~7 年卻產生鉅變，現在應該沒幾個人只用純 html/css/js 做出網站了，大部分都是以前端框架出發搭配一大堆的 dependencies (SCSS preprocessors、task managers、npm、typescript…) 。當團隊發展到一定規模又會分出好幾個不同產品，每一個產品使用的 dependencies 都不大相同使得維護變得困難，到底要怎麼做到避免重覆原始碼以及分好責任歸屬呢？通過實際例子來介紹一下。

若 shop.com 公司今天有數個專案，每一個專案都有不同負責的團隊.

購物網站 shop.com (React)
結帳 shop.com/cart

購物網站手機版 m.shop.com (不是 RWD，是獨立網站)
後臺 admin.shop.com (Vue)
分析使用者網站 analytics.shop.com (Angular)

Note. 雖然不同專案你可以選擇用不同前端框架，但若都用同一種會看到 monorepo 的更大好處。

image.png

shop.com 跟 shop.ocm/cart 雖然是在一個 domain 底下，但負責的卻是完全不同的團隊

image.png

在這種複雜的架構下，我們比較熟悉的方法為 Monolith 跟 Multi repo [延伸閱讀: 初探 Micro Frontends 程式架構]

Single-repo Monolith ?

image.png

最開始大家都是使用這種架構開發的，但隨著前端工程日益複雜，前端需要做的事越來越多、更多 dependencies 被引入，在 Single-repo Monolith 架構下整包會變超級肥大，部署時也必需要整包一起，想當然爾 delopy 時間都爆久，這樣的架構缺點很明顯，也無法達到高擴充性與高效率的組織開發。

Single-repo Monolith 
apps
  ├ node_modules
  ├ libs // 放 share 的東西
  ├ design-systems 
  | ├ node_modules
  | ├ xx...
  ├ shop 
  | ├ node_modules
  | ├ cart
  | | ├ xx...
  | ├ xx...
  ├ shop-mobile
  | ├ node_modules
  | ├ xx...
  ├ admin
  | ├ node_modules
  | ├ xx...
  ├ analytics
  | ├ node_modules
  | ├ xx...
  ├ e2e
  | ├ xx...

Multi repo ?

image.png

現在大部分的前端會採用 Multi repo，每一個獨立案子都會有相對應 repo，團隊各自維護自己 product，釐清責任也很容易

Design-systems Repository
design-systems
  ├ node_modules  
  ├ e2e
  ├ xxxx
Shop Repository
shop 
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Shop Cart Repository: Cart Cart 因為隸屬另一個團隊所以會拆分成兩個 Repository
shop-cart
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Mobile Version Repository
shop-mobile
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Admin Repository
admin
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Analytics Repository
analytics
  | ├ node_modules
  | ├ e2e
  | ├ xx...

看似不錯，但問題又來了

重覆配置

Multi repo 因為每一個 repo 都是獨立的，所以必須建自己的 webpack、開發環境、如何 deploy 等等，若十個 repo 就要維護這 10 個配置，若 repo 之間都不一致，那管理很麻煩

共用程式碼維護成本變很高

projects 間許多邏輯是重複的，但因為不同 repo，所以在 debug 時就要一次修五份，維護耗時耗力成本相當高。你可能會想那把會重複用到的東西另外拉出來單獨創一個 libs Repository，直接改 libs 得東西即可，那流程就會變成改

  • libs Repository，version 從 1.0 到 1.1 2.
  • shop、shop-mobile、admin、analytic 安裝最新的 libs 1.1
  • commit 變動，再 push 更新個自 repo，等待 deploy

這也是 Multi repo 最常被抱怨的事，因為 Repo 被切得太細了，導致只是 share code 小改動流程也超複雜，所花時間也相對變很高。

dependencies 的版本管理變異常複雜

react 17.0.2 而 shop 還在 15.6，若新版本捨棄某些支援，就會產生 bug。或是因為沒有及時 pull 最新的 libs Repo 所以更新不及時而產生 bug。

Mono repo ?

image.png

Mono repo 可以解決上面 Multi repo 的痛點，由於只有一個 Repo 所以管理起來很方便，一個 webpack 、一個 test suite runner 、共用 dependency 若有變動，那有用到此 dependency 的 project 都會知道，並且因為只有個 repo 所以大家都是使用最新的 code 不會用更新不及時的狀況。

apps
  ├ design-systems
  ├ design-systems-e2e
  ├ shop
  | | ├ cart
  ├ shop-e2e
  ├ shop-mobile
  ├ shop-mobile-e2e
  ├ admin
  ├ admin-e2e
  ├ analytics
  ├ analytics-e2e
node_modules
libs
  ├ utils

libs 下面可以放任何會被共用的東西，例如 design systems、TS Interfaces、JS Utilities 等等。這樣架構各自團隊是隻專注自己的專案，例如 shop-mobile team 只會改這個 folder 裡的東西，build 時也可以單獨跑 shop-mobile only。

雖然 monorepo 是主打 一個 repo，一個 package.json，但自己公司還是會把一些 team specific 的 package 放到自己的 folder 裡面，例如很確定只有 design-system 有用到 gatsby。所以這邊設定還是可以針對自己公司做調整，但若這個 package 未來很有可能被別的 team 用，最好也是放到最外層。

apps
  ├ design-systems
  | ├ node_modules
  ├ design-systems-e2e

優點

  • 統一管理 configs and tests: 因為只有一個 repo 所以不需要再重覆配置環境，包括 CI/CD、unit、e2e、webpack 都只需要維護一份就好
  • 部署時間很快: 雖然是同一個 repo 但可以針對不同案子設定 CI/CD 個別部署。若 share code 有變動，你不需要 pull request multi-repo 的每一個專案，而是隻要去更新有用到此 share code 的案子即可。

image.png

  • 管理 dependency 變很容易: 一個 repo，一個 package.json
  • 能生蠔利用 share code (libs)
  • 編譯時間: 使用 monorepo 編譯時間並不會變慢，因為使用好的 monorepo 工具 (例如 nx) 都幫你做好快取跟效能優化了

當然，monorepo 還是有一些缺點

  • codebase 龐大
  • 所有人都可以改動別的 team 的 code: 因為只有一個 repo，但這不是大問題，因為把 code push 上去都需要經過 pull request 稽核，若隨便都被 approved 那就是沒有管理好了。
❌
// shop.js
import 'adminTools' from 'admin'

想要匯入 monorepo，自己是蠻推薦 Nx，官方檔案寫的很清楚也搭配一些視訊教程。

總結

當然並不是每一個專案都適合使用 monorepo 管理，還是要針對專案內容選擇合適的架構，但總體而言若專案夠龐大、又有不同團隊處理不同專案， monorepo 就蠻適合的

程式碼部署後可能存在的BUG沒法實時知道，事後為了解決這些BUG，花了大量的時間進行log 除錯，這邊順便給大家推薦一個好用的BUG監控工具 Fundebug。

原文：https://medium.com/hannah-lin...

交流

有夢想，有乾貨，微信搜尋 【大遷世界】 關注這個在凌晨還在刷碗的刷碗智。

本文 GitHub https://github.com/qq44924588... 已收錄，有一線大廠面試完整考點、資料以及我的系列文章。

相關文章