WeLife 是四人小組共同完成的「自助生活體驗平台」（學校／團隊專題作品）。我們想做的事很直白：把 娛樂（電影）、旅遊（附近景點／路線）、個人空間 收進同一個 Web App，讓使用者感覺「生活資訊不用再開五個分頁」。
產品範圍
前台主要頁面：
- 首頁：熱映電影＋定位附近景點快覽
- 電影：列表、搜尋、類型篩選、詳情與預告（接 TMDB）
- 旅遊：定位／搜尋地點、附近景點、多點距離與導航輔助
- 登入／個人空間：帳號、電影偏好標籤、簡易個人頁
探索頁與部分個人頁功能偏原型（靜態卡片、模擬收藏），真正能穩定 demo 的主軸是 電影＋旅遊＋帳號。
分工與架構
| 區塊 | 技術 |
|---|---|
| 前端 | React 18、Vite、React Router、Bootstrap |
| 會員資料 | Cloud Firestore（偏好標籤等） |
| 旅遊代理 API | Serverless Functions（Express）包裝地圖／地點相關請求 |
| 部署 | 靜態前端＋雲端函式 |
旅遊功能若把地圖 API Key 直接暴露在瀏覽器，風險與額度都不好控，因此把 geocode／nearby／route 等請求放到雲端函式代打——這是這個專題裡我覺得最值得寫的架構決定之一。
早期後端還嘗試過本機 Express＋關聯式資料庫的行程 CRUD；後來產品以即時地點資料為主，那條線成為過渡產物。這種「邊做邊收斂資料源」在專題很常見，重點是最後對外能講清楚真正上線路徑。
學到的事
- 外部 API 要分層：公開內容 API 可前端打（搭配環境變數）；金鑰敏感的地圖請求較適合作後端代理。
- 四人協作要先畫邊界：電影頁、旅遊頁、登入 UI、雲端函數，邊界清楚才不會互相蓋檔。
- 誠實定義 MVP：不是每個選單都要等完整社群／聊天才叫完成；先讓主路徑可展示。
- 帳號系統取捨：本專題以簡易帳號偏好為主（教學取向）。若重做正式產品，會優先評估完善的身分驗證方案。
結語
WeLife 讓我練習的是「把多個第三方能力縫成一個產品故事」。技術可以換，但產品敘事要一致：打開 App 的人，知道自己接下來要看電影還是規劃週末行程。