產品經理面試：B2B SaaS 是否應該推出 GraphQL API？

題幹與適用場景

你負責一個已有 REST API 的 B2B SaaS。大型客戶希望用 GraphQL 自主組合跨資源查詢，工程團隊擔心查詢成本、權限邊界、快取和長期治理。請判斷是否推出 GraphQL API，並說明範圍、指標、風險和遷移計畫。

這道題考察 API 產品決策，不要求現場實作 GraphQL 伺服器。GraphQL 規範把它定義為描述資料模型能力與需求的查詢語言和執行引擎；GitHub 的公開 API 同時支援 query 與 mutation。你的任務是把技術能力轉化為可驗證的產品選擇。

面試官考察點

• 能否從客戶工作流和可量化痛點出發，而不是因為技術流行就選 GraphQL。
• 能否比較 REST、GraphQL 和組合層在可發現性、呼叫次數、權限、快取、可觀測性上的成本。
• 能否把 schema、查詢複雜度、分頁和 mutation 邊界變成產品限制。
• 能否設計分階段試點、相容策略、定價和開發者體驗指標。

回答前需要釐清的問題

• 客戶需要的是減少往返、跨資源聚合，還是更彈性的欄位選擇？現有 REST 是否已能透過聚合端點解決？
• 首批消費者數量、語言棧、合規區域和成功 SLA 是什麼？是否有外部合作夥伴依賴穩定契約？
• 只讀查詢是否足夠，還是必須支援寫入？寫入是否需要交易、冪等和審批？
• 哪些資源和欄位屬於租戶邊界？查詢深度、回傳大小和每租戶預算如何限制？

30 秒回答框架

我會先驗證客戶是否有持續的組合查詢痛點，並用一小組只讀資源做試點。若 REST 聚合端點已能低成本滿足需求，我不會為了協定本身推出 GraphQL；若多個客戶都需要不同欄位組合且維護多個專用端點的成本很高，我會推出受限 GraphQL 產品。首期只開放穩定的查詢 schema、分頁和複雜度預算，沿用現有身分與租戶授權，暫不開放任意 mutation。以啟用率、成功率、P95 延遲、查詢成本、支援工單和 REST 遷移率決定擴大或停止。

分步驟深入解答

先定義客戶價值與替代方案

把需求分成三類：減少網路往返、避免過度取數、跨資源聚合。為每類需求記錄目前 REST 呼叫鏈、端到端延遲、維護的專用端點數量和客戶自建代理成本。若新增一個 REST 聚合端點能解決大多數高價值場景，就應把 GraphQL 的治理成本納入比較，而非只比較請求數量。

設計產品邊界而非開放整個資料庫

首期 schema 只覆蓋有穩定語義、明確租戶歸屬和可觀測性的資源。每個欄位都要標註敏感級別、授權規則、版本承諾和資料新鮮度。查詢和 mutation 分開評審；只讀查詢先驗證價值，寫入能力在冪等、稽核和錯誤模型成熟後再考慮。

把查詢成本變成可執行的預算

GraphQL 的彈性選擇集會把成本從端點數量轉移到查詢形狀。平台應限制最大深度、節點數、分頁大小和逾時，並按 schema 欄位或 resolver 估算成本。拒絕超預算請求時回傳可行動的錯誤碼，同時記錄租戶、operation name、成本估算和實際資源消耗。

統一身分、授權與資料邊界

GraphQL 只改變呼叫形狀，不應繞過現有 OAuth、服務帳號、租戶隔離和欄位級權限。授權檢查必須發生在 resolver 或統一資料存取層，避免只在頂層 query 檢查。批量讀取要防止跨租戶拼接、越權快取和錯誤資訊洩露。

規劃開發者體驗與相容性

提供 schema 文件、範例查詢、錯誤指南、分頁約定、operation name 要求和變更日誌。GraphQL schema 的破壞性變化要有棄用窗口、呼叫方掃描和聯絡人名單；REST 與 GraphQL 可以共用領域模型，但不要承諾兩套介面的欄位永遠一一對應。

設定試點、指標與退出條件

選擇 2 至 3 個有代表性的客戶和只讀工作流，設定固定資源範圍與預算。核心指標包括活躍應用數、有效查詢率、P95/P99 延遲、每次查詢成本、越權攔截數、支援工單和客戶完成任務的時間。若採用率低、成本高或治理事故增加，應縮小 schema 或停止擴展，而不是用更多欄位掩蓋訊號。

{
  "pilot": {"tenants": 3, "mode": "read-only", "maxDepth": 6, "costBudget": 100},
  "exit": {"p95LatencyMs": 400, "errorRate": 0.01, "supportTicketsPerTenant": 2}
}

高品質示範回答

我不會把 GraphQL 當作 REST 的必然替代品。先用客戶證據確認組合查詢、欄位過取或專用端點維護是否達到足夠規模；同時比較 REST 聚合層的交付成本。若試點成立，我會把 GraphQL 作為受治理的 API 產品：只開放一組穩定只讀 schema，沿用 OAuth 和租戶授權，要求 operation name，限制深度、節點數、分頁和成本，提供 schema 文件與棄用窗口。Google Apigee 將 API product 視為可組合的資源、方法、存取級別和配額集合，這提醒我們把 GraphQL 的存取控制、額度和方案一起設計。試點用活躍客戶、成功率、P95、單位查詢成本和支援負擔評估，達不到退出條件就停止擴展；達到條件後再增加資源和有限 mutation。

常見錯誤

• 只說「前端更靈活」，沒有證明客戶價值或比較 REST 聚合方案。
• 把 GraphQL schema 直接映射資料庫表，忽略領域語義、權限和敏感欄位。
• 允許無限深度、無限分頁或任意巢狀，未回答成本與拒絕策略。
• 把 query 和 mutation 一起開放，卻沒有冪等、稽核、審批和回滾邊界。
• 只談採用率，不看延遲、成本、越權攔截和支援負擔。
• 承諾一次性遷移全部 REST 客戶，忽略雙軌文件、棄用和回滾。

追問及應對

如果客戶只想減少請求次數，為什麼不做 REST 聚合端點？

先用呼叫鏈和維護成本量化兩種方案。固定、高頻且邊界清晰的工作流適合聚合端點；需求組合持續變化、多個客戶需要不同欄位選擇時，受限 GraphQL 的邊際價值才更高。可以先把同一批工作流做 A/B 試點，再決定協定範圍。

如何防止 GraphQL 查詢拖垮後端？

在入口做深度、節點數、分頁和逾時限制，在 schema 層維護成本權重，在 resolver 層做批量讀取和快取，並按租戶配額和優先級限流。拒絕請求時記錄 operation name、估算成本和資源消耗，避免只回傳模糊的伺服器錯誤。

什麼時候開放 mutation？

當只讀 schema 的授權、錯誤、稽核和可觀測性穩定後，再選擇低風險、冪等且可補償的寫操作。每個 mutation 需要明確輸入驗證、衝突語義、權限、稽核事件和失敗重試；財務、刪除或跨租戶操作應繼續走專用工作流。

如何與 REST 共存？

保留 REST 作為穩定相容面，GraphQL 先覆蓋新工作流，不要求欄位一一映射。統一身分、領域權限、稽核和 SLO，分別記錄呼叫方遷移率與兩套介面的成本。只有當客戶價值、營運成本和相容風險都得到證據支持時，才討論棄用某個 REST 能力。