日系電商平台

Overview專案概述

My Contribution我負責的事

1. 01採用 Orval 自動生成 API Client，實現 28+ 個端點的型別安全整合。
2. 02使用 Composables 模式建立可重用狀態管理邏輯，確保 SSR/CSR 狀態一致性。
3. 03整合 Google OAuth 2.0 第三方登入與 Token 持久化機制。
4. 04實作 API 快取與去重機制（useApiCache），優化請求效能。
5. 05設定 SEO Meta Tag、Schema.org 結構化資料與 useSeoMeta 動態優化。
6. 06建立完整後台管理系統：商品、分類、訂單、優惠券、輪播圖等模組。

Problems & Decisions問題與決策

這個電商平台同時包含顧客購物介面與商品、訂單管理後台。會員、購物車、收藏與訂單會在多個頁面共用資料，因此開發重點是讓首屏與後續操作保持一致，並能跟上後端規格的更新。前端以 Nuxt 3、Vue 3 與 TypeScript 建置，使用 Orval 產生 API 呼叫方法，整合 28 個以上端點。

1. CASE 01

   Orval API Client 自動化生成

   Finding

   電商前後台 API 端點多，手寫呼叫方法與型別時，規格更新容易漏改。

   Decision

   用 Orval 從 OpenAPI 生成 TypeScript Client，讓 API 規格變更能反映到前端型別與呼叫方法。

   Result

   完成 28 個以上端點串接，呼叫方法與 TypeScript 型別由 Orval 從 OpenAPI 規格產生。

2. CASE 02

   SSR / CSR 狀態一致性與 Composables

   Finding

   登入、購物車、收藏與訂單狀態同時出現在 SSR 首屏與 Client 互動流程，狀態來源分散會導致 hydration 與跨頁行為不穩。

   Decision

   以 Composables 與 useState 收斂狀態來源，讓共享狀態在頁面、元件與 SSR / CSR 邊界間有一致的更新方式。

   Result

   登入、購物車、收藏與訂單共用狀態來源，供伺服器渲染與瀏覽器互動使用。

3. CASE 03

   請求快取與失效邊界

   Finding

   商品、會員、購物車與收藏資料會被多個頁面重複讀取，若沒有快取與失效邊界，容易造成重複請求或顯示舊資料。

   Decision

   建立 useApiCache 的 TTL、請求去重與失效邏輯，並和登入 / Token 狀態一起整理資料更新時機。

   Result

   完成 useApiCache 的 TTL 快取、請求去重與失效邏輯，配合登入與 Token 狀態處理資料更新時機。