产品经理面试：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 能力。