為什麼要重新設計後端架構？從技術債務到系統化重構

四年接案路上的後端技術混亂
在過去四年的接案經驗中，我使用了各種後端技術組合來快速交付專案：

• 語言大混戰：Python/FastAPI、Kotlin/Spring Boot、Go/Gin、Node.js/Express
• 資料庫選擇分散：MySQL、PostgreSQL、MongoDB、Redis
• 部署方式混亂：從傳統 VPS 手動部署到 Docker，散布在 Vultr、AWS、GCP
• API 設計不一致：REST API文件與實作常常不同步

這種多語言、多框架的技術債務逐漸浮現：

• 維護噩夢：每個專案需要不同的開發環境和知識背景
• 邏輯重複：認證、授權、驗證、錯誤處理在各專案中重複實作
• 部署困擾：每個服務的部署流程都不同，監控和日誌分散各處
• 擴展困難：客戶需求變化時，需要重新評估整個技術架構
• 團隊協作難：新成員需要學習多套技術棧才能有效協作

Kyo-System 後端重構策略
為了解決這些根本問題，決定打造一個可「長期維護、彈性擴展、模組複用」的 SaaS 後端系統：

技術統一化策略：

• 全端 TypeScript：前後端共享型別定義，降低心智轉換成本
• ORPC 函式即 API：前端到後端實現「函式即 API」，型別端到端一致
• 微服務模組化：以單一責任起步（Kyo-OTP），逐步擴展 Kyo-User/Kyo-Booking
• 私有套件庫：@kyong/kyo-* 沉澱核心邏輯與 UI 元件，支援快速客製化
• 雲原生部署：從 Vultr 遷移到 AWS 託管服務，實現自動化部署與監控

這次鐵人賽挑戰主要是為了把以前所留下的各種語言框架以及技術在做一個整合，也打算打造出一個SaaS產品來跳脫每個專案都客製化而無法快速擴展客戶。