PM_39 給 PM 的一頁摘要:Apple 登入的一個技術選擇,建議開工前確認
- 日期:2026-05-20
- 對象:Eric(PM)
- 對應 PRD:PM_39
third-party-auth-mockup.md(v1.6.0 起;v1.5.0 以前檔名為third-party-auth-firebase-mockup.md) - 這份文件要你做的事:花 5 分鐘讀完,決定是否讓 RD 重新評估一個技術選項(§4)
一句話
PRD 整體很完整、品質很高。但裡面有一個技術選擇(Apple 登入背後接哪條線)是 5/18 就定案;之後幾輪 review 雖有重複提到它,卻沒有人查證它當初的理由是否仍成立——它其實值得在 RD 動工前再確認一次。這不影響 PRD 任何商業規則、流程、畫面或使用者體驗 —— 純粹是後端架構選擇,使用者完全無感。
後續結論(2026/05/22):PM 採納本文件建議,選 A 原生,PRD 已於同日由 v1.5.0 收斂為 v1.6.0(詳見 PRD §1 文件資訊與 §17.6 v1.6.0 收斂紀錄)。
1. 這個選擇是什麼
「使用者按 Apple 登入後,後端怎麼驗證身份」有兩種做法:
- A. 原生:wport 後端直接驗證 Apple 的登入憑證(跟現在 Google 登入是同一種做法)。
- B. 透過 Firebase:多接一個 Google 的服務(Firebase)當中間人。
PRD 目前選了 B(Firebase)。
2. PRD 為什麼選 Firebase
PRD 給了兩個理由:(一)Apple 的 email 只給一次,Firebase 幫忙保存比較保險;(二)Apple 在網頁登入很麻煩,Firebase 幫忙包掉。
3. 查證後發現
- 理由(二)已經過時 —— Apple 現在的網頁登入早就能做到跟 Google 一樣的彈出視窗,不會打斷頁面。這個理由不成立。
- 理由(一)是真的,但被講得太嚴重 —— 後端只要把資料正確地一次寫進資料庫就沒事,而且就算極端情況也有補救方式。Firebase 帶來的保險很有限。
- 更關鍵的盲點:PRD 把 Firebase 講成「幫我們扛麻煩」,但實際上 Firebase 反而讓這個專案多出工 —— PRD 裡最複雜、最容易出錯的「三層撤銷」,其中整整一層(撤銷 Firebase 端)就是因為接了 Firebase 才存在;帳號刪除時也多一道「清除 Firebase 上的使用者紀錄」。不接 Firebase,這一層與這道手續直接消失。但要講清楚:撤銷 Apple 端、接收 Apple 的帳號狀態通知、清除我們自己的登入狀態——這幾項改成原生一樣要做。省下的是「Firebase 那一層」,不是全部。
- 接 Firebase 還等於多讓一個 Google 服務保管我們使用者的個資,對個資法來說是多一個要顧的點。
4. 兩個選項對 PM 的影響
| 面向 | A. 原生(建議) | B. Firebase(PRD 現案) |
|---|---|---|
| 開發量 | 較少(可砍掉一部分撤銷/刪除的工) | 較多 |
| 對上架時程 | 較有利 | 較不利 |
| 跟現有系統一致性 | 一致(同 Google 做法) | 多一套架構 |
| 個資法面 | 較單純 | 多一個外部資料保管者 |
| 使用者體驗 | 完全相同 | 完全相同 |
補充:PRD 提到「先建 Firebase,以後 LINE / LinkedIn 可以重用」。但 PRD 自己也寫了那個重用方式還沒驗證、可能要付費;而且 Google 登入永遠不會搬進 Firebase。所以「統一架構」這個好處其實也拿不到。LINE / LinkedIn 之後走原生一樣可行。
5. 不會受影響的部分(請放心)
PRD 的所有商業規則(唯一信箱、防呆解綁、自動合併、安全 gate…)、流程、畫面、文案、客服 SOP —— 全部不變。這個選擇只決定「後端內部接線方式」,改了使用者也看不出差別。唯一要小修的是 PRD 裡描述後端架構的幾個技術段落。
6. 建議
請 RD 與 PM 在 RD 開始寫 API 規格前,花約 30 分鐘把這個選擇重新確認一次:
- 如果決定改成原生 → 開發量較省、對上架較有利,PRD 改幾個技術段落即可。
- 如果決定維持 Firebase → 也可以,但請把「Firebase 帶來的額外開發量」明確算進 RD 工時,並在 PRD 凍結表補一句「此決策已於 2026-05-20 複審、確認維持」,讓決策留下紀錄。
兩種結論都能接受。重點只是:讓這個選擇變成「看過利弊後做的決定」,而不是「定了之後就沒人查證理由是否仍成立」的狀態。
技術細節、完整查證與程式碼對照,見 RD 版文件:
W101-TalentSearchHub/docs/superpowers/specs/2026-05-20-pm_39-apple-auth-native-vs-firebase-design.md