在正式開始開發之前，先花一點時間把整個專案規劃好。

畢竟鐵人賽只有三十天，如果做到一半才發現功能太多、架構不適合，後面就很容易需要重新來過。

核心功能

我先把整個 App 拆成幾個主要功能：

使用者

• Google 帳號登入

散步

• 自由散步並記錄實際走過的 GPS 路線
• 暫停、繼續與結束散步
• 查看每次散步的路線圖、距離、時間等資訊

推薦路線

• 根據散步時間與偏好產生推薦路線
• 跟著推薦路線散步
• 記錄實際路線並計算推薦路線完成率

統計

• 散步統計
• 成就系統
• Widget
• 散步分析
• 散步教練

資料同步

正式完成的散步資料都以後端為準。

散步進行中的 GPS 點則先暫存在 SQLite，就算突然斷網、App 被關閉或手機重新開機，也可以等恢復正常後再繼續同步，不會直接遺失整趟散步紀錄。

技術棧

我這次沒有特別追求新技術，而是盡量選擇自己比較熟悉，也適合長期維護的工具：

App

• React Native
• TypeScript
• Zustand
• TanStack Query
• react-native-maps
• SQLite
• Google Sign-In

之所以沒有用 Expo，是因為後面會做到背景定位、Widget 等原生功能，直接使用 React Native Community CLI 會比較彈性。

狀態管理則分成兩種：

• Zustand：管理目前散步狀態等 App 內部狀態。
• TanStack Query：管理後端資料與快取。

這樣兩者的職責會比較明確。

後端

• Cloudflare Workers
• Hono
• TypeScript
• Zod
• Turso
• Drizzle ORM
• Cloudflare R2
• Google Places API
• Google Routes API
• Gemini API

後端主要負責身分驗證、正式資料保存、推薦路線、統計計算以及 AI 功能。

系統架構

整個架構大概如下：

App
│
├── Google Sign-In
├── GPS 路線追蹤
├── 地圖顯示
├── 即時散步狀態
├── SQLite 暫存
├── Zustand
├── TanStack Query
└── Backend API
        │
        ▼
Cloudflare Worker
│
├── Google Token 驗證
├── Session 驗證
├── Walk API
├── Route API
├── Achievement API
├── Statistics API
├── AI API
└── Upload API
        │
        ├── Turso
        ├── Cloudflare R2
        ├── Google Places API
        ├── Google Routes API
        └── Gemini API

專案結構

因為這個專案同時包含 App 和後端，所以我決定使用 Monorepo。

如果拆成兩個 Repository，像是 API 型別、Zod Schema 或一些共用工具，都需要另外同步，修改時也比較容易漏掉。

因此整個專案會長這樣：

.
├── apps
│   ├── mobile
│   └── api
├── packages
│   ├── shared
│   └── validation
├── package.json
└── pnpm-workspace.yaml

其中：

• apps/mobile：React Native App。
• apps/api：Cloudflare Workers 後端。
• packages/shared：前後端共用型別與工具。
• packages/validation：共用 Zod Schema。

例如新增一個 API 時，Request、Response 型別和驗證規則都可以放在 packages 裡，前後端直接共用同一份定義，不需要各自維護一份。

小結

真正開始寫功能之前，先把整體架構想清楚，這樣後面每增加一個功能都只是在既有架構上擴充，而不是做到一半才發現有問題需要重寫。

明天就會先從登入開始，完成 Google 帳號登入，以及 App 第一次啟動時最基本的登入流程。