GraphQL 架构风格

2015 年，Facebook 开源了 GraphQL，一种旨在解决 REST API 过度获取和不足获取问题的查询语言。传统的 REST 架构要求客户端根据服务端的固定端点获取数据，而 GraphQL 将数据结构的定义权交给客户端，让前端开发者能够精确指定需要哪些字段。

核心概念：Schema 与 Resolver

GraphQL 的核心是强类型的 Schema，它定义了 API 中所有可查询的数据结构。Schema 使用 GraphQL Schema Definition Language（SDL）来声明类型、字段和它们之间的关系。

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
}

type Query {
  user(id: ID!): User
  posts: [Post!]!
}

type Mutation {
  createPost(title: String!, content: String!, authorId: ID!): Post!
}

Resolver 是解析每个字段的函数。当客户端发起查询时，GraphQL 会根据 Schema 中的字段定义，调用对应的 Resolver 获取数据。这种设计将数据获取逻辑完全解耦，每个字段可以独立选择数据源，甚至跨越多个微服务。

客户端驱动 vs 服务端驱动

REST 的一个根本限制是 服务端驱动：后端开发者预先定义好返回哪些字段，客户端只能被动接受。相比之下，GraphQL 的查询语法将选择权完全交给客户端。

# 客户端可以精确指定需要的字段
query {
  user(id: "1") {
    name          # 只要姓名
    email         # 只要邮箱
    posts {       # 只要文章的标题
      title
    }
  }
}

这种设计在移动端尤其有价值——不同的设备对数据量有不同的敏感度，手机端可以只请求必要的字段来减少流量消耗。然而，这并不意味着 GraphQL 总是更好的选择。REST 在缓存控制、CDN 友好度、以及 API 文档化方面仍然有优势。两者并非非此即彼的对立关系，而是适用于不同场景的工具。

N+1 查询问题与 DataLoader 解决方案

GraphQL 最著名的性能陷阱是 N+1 问题。当查询一个用户列表及其关联的 posts 时，Resolver 可能为每个用户单独执行一次数据库查询，导致 N+1 次数据库往返。

# 看似简单的查询
query {
  users {
    name
    posts { title }
  }
}

如果直接实现 Resolver，users 会执行一次查询，然后 posts 为每个 user 单独执行一次查询，100 个用户就是 101 次数据库查询。

DataLoader 是 Facebook 提出的标准解决方案。它通过批处理和缓存，将同一批次中对同一类型资源的多次请求合并为一次数据库查询。DataLoader 的核心是一个异步批处理函数，在事件循环的下一个 tick 之前，收集所有 pending 的请求，然后统一发送一条批量查询。

Schema 设计最佳实践

良好的 GraphQL Schema 需要平衡灵活性和可维护性。首先，避免过于扁平的 Schema。把所有字段堆在一个类型里会导致类型膨胀，难以理解和演进。其次，使用连接（Connection）模式处理列表。当返回对象列表时，遵循 Relay Cursor Connections 规范，提供分页和游标支持，而不是简单的数组。

type User {
  posts(after: String, first: Int, before: String, last: Int): PostConnection!
}

type PostConnection {
  edges: [PostEdge!]!
  pageInfo: PageInfo!
  totalCount: Int!
}

Schema 变更需要格外谨慎。添加字段通常是向后兼容的，但删除或修改字段需要遵循版本管理策略。宁可废弃不用，也不要直接删除，通过 @deprecated 指令标记并提供迁移时间窗口。

适用场景与局限

GraphQL 适合复杂前端、对数据精确性要求高的场景，特别是 B2C 移动应用和多个前端客户端需要不同数据视图的情况。但它不适合简单的 CRUD 服务、高并发写入场景，或者需要强缓存控制的后端系统。在微服务架构中，GraphQL 通常作为 BFF（Backend for Frontend）层，聚合多个下游服务的数据，而不是直接暴露给所有客户端。

#GraphQL 架构风格

#核心概念：Schema 与 Resolver

#客户端驱动 vs 服务端驱动

#N+1 查询问题与 DataLoader 解决方案