WORK STORY / 04

建置並維護跨產品 Frontend Shared Packages

CONTEXT

情境

Gorilla 是我第一次真正進入一個大量使用 Frontend Shared Packages 的開發環境。

公司的產品會使用許多共通的資料分析與視覺化能力，這些能力並不是每個 Application 各自重新實作，而是被整理成 Packages，再提供給不同產品組合使用。

其中包含像地圖互動、資料分析與其他共用前端能力。

這跟我以前理解的「抽幾個 Common Components」很不一樣。

這些 Package 本身就是需要被設計、發布、升級與長期維護的產品。

DECISION & ACTION

我的判斷與做法

我開始參與 Shared Packages 的建置與維護，也第一次真正面對：

什麼東西值得成為跨產品能力？

如果把 Application 特有的業務邏輯一起塞進 Package，共用層很快就會被某個產品綁死；

但如果 Package 抽象得太薄，每個產品又必須在外面重做大量相同整合。

所以在實作資料分析、地圖互動等能力時，我開始更在意：

  • Package 應該負責到哪裡
  • 哪些差異應該透過 API / Config 傳入
  • 哪些狀態應該留在 Application
  • 如何讓不同產品使用同一套核心能力，而不互相知道彼此的業務

後來這些 Shared Packages 也成為導入 Nx Monorepo 時非常重要的一部分，因為 Package 與 Consumers 的依賴關係終於可以放在同一個 Workspace 裡管理。

OUTCOME

形成的結果

資料分析與共通前端能力可以由 Package 統一維護，再由不同產品依照自己的需求組合使用。

對我來說更重要的是，我第一次真正接觸到：

把前端能力當成 Platform Building Block 來設計。

而不是每遇到一個產品需求，就在 Application 裡重新完成一次。

REFLECTION

留下的思考

這段經驗對我後面的影響很大。

以前談「共用」，我比較容易想到：

共用 Function、共用 Component。

在 Gorilla，我開始理解更大的共用單位可以是一整套完整能力：

它有自己的責任邊界、API、版本與生命週期，再被不同產品依賴。

這也成為我後來在 Clinico 持續做 Shared Architecture、LIFF 共用層與 Monorepo 時的重要基礎。