2025 年 6 月 19 日的 C Talk+ 中，我們邀請到網頁前端工程師的 Ben，和大家分享前端團隊是如何運用微前端（Micro Frontend）的概念、Monorepo 架構，以及從 RESTful API 過渡到 GraphQL，來解決實際問題、加速開發流程，並提升團隊協作效率。
前言 ── CMoney 前端轉型故事
「一支再大的蠟燭，它的光度都是有限的；但一支小蠟燭點著而引燃千萬支蠟燭後，這千萬支的燭光可以照亮千萬個黑暗的角落。」
這句話陪伴我們完成前端架構的大手術。過去，CMoney 理財寶的所有功能塞在同一個網頁專案裡——首頁、影音頁、商品頁，彼此牽一髮動全身。團隊之間互相卡位、部署頻率也被綁在一起，甚至常常只是為了修改一個活動頁的文案，整個網站都要重新打包一次，這對效率是很大的負擔。
「一個簡單的修改，如果拖慢了整個團隊節奏，那就表示我們的架構設計需要調整了。」
一、把巨獸切成樂高：微前端的誕生
想像一座商場只有一扇大門，顧客無論買咖啡還是看電影都得擠同一條動線；久而久之，門口必塞車。微前端做的，就是把這扇門拆成多個獨立入口——線上課程、作者工具、金流模組各有自己的大門和服務人員。
當「線上課程」想在雙 11 換新版型時，若線上課程頁被獨立出來，團隊就能自行修改、測試與上線。因為檔案較小、耦合性較低，部署不需牽動整個主站流程，也自然減輕主站開發團隊的壓力。。
這類拆分並非萬能，如何分配 domain ownership、處理路由整合、部署的版本控制等等都是需要思考的挑戰，這些我們並不是一開始就想清楚，而是邊拆邊調整、邊踩雷邊修正。例如有一次兩個模組路由衝突，結果整個主站首頁變白畫面…這也讓我們學會了，技術導入不只是寫 code，更包含流程與觀念的同步。
二、讓零件規格一致：Monorepo 出場
當模組拆分之後，如果每個團隊在調整時都各自複製一份相同的「按鈕元件」，很快就會出現樣式不一致、行為不一樣的狀況。更麻煩的是，某些模組可能修了 bug，其他模組卻還在用舊版，久而久之，整個使用者體驗就會變得破碎。這樣的問題不只出現在 UI 元件，像是表單驗證邏輯、登入流程、甚至時間格式轉換等共用邏輯，也可能因為各寫各的而出現行為不一的情形。
為了解決元件分歧與重複開發問題，我們導入了 Monorepo 架構。Monorepo 就像一座規劃有序的倉儲中心，不同元件有專屬貨架、清楚標籤，讓團隊可以快速找出正確版本、集中維護。
我們的 Monorepo 主要可以對應到兩個主資料夾：
- libs 放共用元件與 API，可以被所有模組引入的內部套件。我們可以很輕鬆地在各個模組之間共用元件，而且修改之後可以同步測試、統一版本控管，避免出現「有的更新了、有的沒跟上」這種狀況。未來如果要改樣式、加選單，只要改一處就可全站套用。
- apps 則放獨立出來的各個子專案，例如你只改了「線上課程」裡的按鈕文字，CI 腳本只需要針對那個 app 重新打包部署，不需動到其他無相關專案。
微前端的概念，讓每個模組都可以獨立開發與部署，萬一有哪一個地方出錯，也不會牽連到其他模組，且個別模組可以快速上線，大幅加快開發節奏。
而 Monorepo 的 CI/CD 機制也讓我們可以針對有改動的模組自動建置與部署，讓每個子專案可以獨立構建、讓共用資源集中管理，不會被其他專案阻塞，也避免重工，確保開發流程順暢。
三、換條更靈活的水管：GraphQL 補位
我們系統的前端頁面，往往需要從多個後端服務抓取資料。例如訂閱頁面，同時需要用戶基本資料、訂單資訊、優惠券狀態等等。用傳統的 RESTful API 設計方式，我們往往要對應四、五個 API 端點，各自發請求、整理資料、處理錯誤。
為了解決這個問題，我們團隊後來開始導入 GraphQL，這一種由 Facebook 推出的 API 查詢語言，用來彈性取得資料，前端可以決定自己要什麼資料欄位。
例如當 PM 或設計突然說「欸我們想多加一欄叫做『最後登入時間』」，過去我們會先開會、討論欄位格式、請後端評估怎麼改 API、然後等後端開發量能的釋出。現在我們先查一下 schema 裡有沒有這個欄位，如果有，直接在 query 裡加進去就可以了，不到幾分鐘就能讓畫面顯示出來，PM 也可以立刻驗收，更重要的是，我們降低了與後端協作時的等待與溝通成本，也讓前端開發者有更多主動性去回應需求。
然而實務上，我們沒有把 REST 全面淘汰，下單、付款這種「先後流程嚴謹且具明確定義」的指令仍交給 REST；而資料查詢與前端需要多資料源整合的情境則交給 GraphQL。工具沒有高下，只有「適不適合」。
想動刀？三個實作面向來著手！
如果你所在的團隊正受「單體巨獸」所苦，以下三項是我們驗證過、代價最小卻能立刻見效的做法，你可以依序嘗試：
| 做法 | 該如何開始 | 技術效果 |
| 微前端 | 把「改動最頻繁但依賴最少」的頁面（例如活動 Landing Page）獨立成子網站，給它專屬 deploy pipeline。 | 讓模組獨立、提升部署彈性與錯誤隔離能力 |
| Monorepo | 凡是出現三次以上重複的程式碼（不論是 UI 元件如 Logo、Button、日期選擇器，還是邏輯 function 像是 API 包裝器、共用驗證規則、登入狀態檢查），統一搬進 Monorepo 的 libs 資料夾中。 | 幫助我們集中管理共用資源、減少重複開發、提高維護效率 |
| GraphQL | 挑一支「跨端共用、讀多寫少」的 API（例如使用者個人資料）改成 GraphQL，前端一次取齊欄位。 | 我們在資料取得上更具彈性，不再被 API 規格限制 |
結語 ── 把蠟燭交到下一個人手上
我們常說「寫程式是在解決問題」，微前端、Monorepo、GraphQL 只是火柴盒裡的三根火柴，點燃之後能不能照亮整條道路，取決於你願不願意把它們傳遞下去。
如果你正在規劃拆 monolith，或卡在 CI 動輒半小時、PR 永遠排不到 Review——帶著本文的三步試試看，希望能幫助下一位工程師少走冤枉路。蠟燭越傳越多，黑暗才會越來越少。
CMoney 是幫助用戶做好人生投資的全方位平台，涵蓋金融、消費、社群三大事業群，並由 X 實驗室持續驅動創新。
從籌碼K線、股市爆料同學會、發票載具、英文知識王、到 AI 社群抬槓，我們的產品服務超過 1000 萬用戶和 90% 的金融機構，幫助每個人實現財務成長與生活的全方位成長。
