為什麼需要重新設計前端架構？

在四年接案經驗中，我使用了許多前端技術組合：React、Vue 搭配不同的狀態管理和 UI 框架。每個專案的前端都是獨立設計，導致：

• 技術棧混亂：Redux、Vuex、MobX 都有使用
• 組件無法複用：相似的表單、列表在不同專案中重複開發
• 樣式不一致：每個專案的設計風格都不同
• 維護困難：需要在不同框架間切換思維，心智負擔大

加上去年開了工作室，也該是時候打造屬於工作室的SaaS產品，從而擺脫各種客製化的服務，可以推出一套SaaS產品來尋找機會。
因此決定建立統一的 Kyo-System 前端架構，從前台Dashboard開始，逐步建立組件庫和設計系統。

Kyo-System 前端整體架構

前端採用現代化的技術棧：

┌─────────────────────────────────────────────────────────────────────┐
│                    KYO-SYSTEM FRONTEND ARCHITECTURE                │
└─────────────────────────────────────────────────────────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
        ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
        │  LEGACY SYSTEMS │ │   MANAGEMENT    │ │  MOBILE/PWA     │
        │                 │ │    DASHBOARD    │ │   (Future)      │
        │ • Vue/React     │ │                 │ │                 │
        │ • Independent   │ │ React 19 + Vite │ │                 │
        └─────────────────┘ └─────────────────┘ └─────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                        SHARED LAYER                                │
├─────────────────┬─────────────────┬─────────────────┬──────────────┤
│  @kyong/kyo-ui  │ @kyong/kyo-types│  State Mgmt     │  API Layer   │
│  • Components  │ • TS Interfaces │  • Zustand      │  • ORPC      │
│  • Design Sys   │ • Zod Schemas   │  • Stores       │  • REST      │
└─────────────────┴─────────────────┴─────────────────┴──────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                         BACKEND SERVICES                           │
│                   Fastify + ORPC + TypeScript                     │
└─────────────────────────────────────────────────────────────────────┘

技術棧選型策略

為什麼選擇這些前端技術？

React 19 + TypeScript

• ✅ 生態豐富：豐富的組件庫和工具鏈
• ✅ 型別安全：與後端共享型別定義
• ✅ 新特性支援：React 19 的 Suspense 和 Server Components

Vite 建置工具

• ✅ 快速開發：HMR 和冷啟動速度極快
• ✅ ESM 原生支援：現代化的模組系統
• ✅ Monorepo 友好：與 Turborepo 完美整合
• ✅ 生產優化：Rollup 打包優化

Mantine UI 框架

• ✅ 開箱即用：豐富的企業級組件
• ✅ 暗黑模式：內建主題切換支援
• ✅ TypeScript 優先：完整的型別定義
• ✅ 可訪問性：符合 WCAG 標準

Zustand 狀態管理

• ✅ 輕量簡潔：替代 Redux 的輕量方案
• ✅ TypeScript 友好：天然型別支援
• ✅ DevTools 支援：調試工具完善
• ✅ 持久化：localStorage 整合

目前新的SaaS產品以新需求為主，再慢慢打造出共有服務例如會員、教練、預約之類的服務，首先先以新架構開發OTP簡訊驗證系統。