GraphQL | devexamples

GraphQL 通过类型化 schema 让客户端按需取字段，单一端点换来灵活的数据获取，也牺牲了简单的 HTTP 缓存。

工作原理

schema 声明类型、字段、参数和关系。客户端发送查询文档选择字段，服务器为每个字段调用 resolver 执行。响应形状与查询一致，因此移动端可以只要三个字段，而 Web 端从同一端点取二十个字段。mutation 修改数据，subscription 通过长连接推送更新。

query {
  order(id: "ord_123") {
    total
    customer { name }
    items { sku quantity }
  }
}

由于一个查询可能触达大量 resolver，生产服务器需要深度限制、复杂度评分、超时和持久化查询白名单，只允许已知文档执行。

当客户端的数据需求差异很大、需要 BFF 层聚合多个服务，或产品快速迭代希望客户端新增字段而无需服务端发布时，GraphQL 很有价值。对于只有一两个消费者、以简单增删改查为主的 API，它并不划算。

缓存更困难：单端点 POST 会绕过多数 HTTP 缓存键，团队只能依赖规范化客户端缓存或持久化 GET 查询。授权必须按字段执行，而不只是按路由。resolver 很容易产生 N+1，批处理和查询计划因此成为核心工程工作。schema 演进需要弃用机制，而不只是加字段。

常见误解是 GraphQL 消除了过度获取。它在网络上减少了冗余字段，但若 resolver 为每个条目单独查询客户，就会制造数据库 N+1 风暴；DataLoader 式批处理才能解决，schema 本身不会。相关概念：N+1 查询问题、限流、HTTP 缓存。