[!info] related notes

• 所属 MOC: graphql-moc
• 相关概念:
• 易混淆概念:
• 相关资源:

GraphQL 的历史与生态定位

为什么 GraphQL 会出现

GraphQL 不是为了“发明另一种 HTTP 语法”而出现，而是源于 Facebook 在 2012 年重写原生移动应用时遇到的数据获取问题。

当时移动端页面往往需要把用户、动态、评论、头像等多种关联数据组合成一个视图。固定 REST endpoint 很容易出现：

一个 endpoint 返回太多字段
或
一个页面需要连续请求多个 endpoint

Facebook 因而设计了一套新的数据查询模型：客户端直接描述当前界面需要的数据形状，服务端通过统一的类型系统和执行引擎满足该查询。

时间线

2012
Facebook 内部创建 GraphQL
用于原生移动应用的数据获取

2015
开始建设开放标准
发布公开规范与参考实现
GraphQL 进入开源社区

2017
规范采用 OWFa 1.0 授权

2019
GraphQL Foundation / Specification Project
成为更中立的社区治理体系

2025
GraphQL 发布 September 2025 规范版本
首个公开规范已满十年

最早的规范仓库长期列出的核心贡献者包括 Lee Byron、Nicholas (Nick) Schrock、Daniel (Dan) Schafer。GraphQL 后续已从 Facebook 内部技术演变为由社区和 GraphQL Foundation 治理的开放规范。

它解决的原始问题

GraphQL 的出发点可以浓缩为：

让 UI 的数据需求直接表达成查询，而不是迫使 UI 适应服务端预先切好的 endpoint。

因此它天然强调：

• 强类型 Schema；
• 查询结构与响应结构相似；
• 客户端字段选择；
• 关联对象的组合查询；
• API 的渐进演进。

当前生态位置

GraphQL 已经是成熟 API 技术，但并没有取代 REST。

Postman 2025 State of the API 调查中，REST 仍是最常见的 API 方式（93%），GraphQL 约为 33%。这更适合解读为：

REST = 默认、广泛的基础方案
GraphQL = 在复杂数据组合场景中成熟的重要补充

GraphQL 仍被大型生产 API 使用。例如 GitHub 当前同时提供 REST 和 GraphQL API，并明确把 GraphQL 的“精确选择所需数据”作为其优势。

因此今天学习 GraphQL 的价值不是押注“以后所有 API 都会变成 GraphQL”，而是掌握另一种成熟的 API contract / data-fetching / cache / resolver 心智模型。

为什么它没有取代 REST

GraphQL 消除了某些客户端复杂度，却产生了新的服务端和客户端治理成本：

endpoint / DTO 组合复杂度下降
        ↓
Schema / Resolver / Query Cost / Cache
复杂度上升

简单 CRUD、文件下载、HTTP/CDN 缓存语义明显的 API，REST 常常更直接。

复杂产品页面、多客户端差异化取数、强类型 schema tooling 等场景，GraphQL 的收益更明显。

资料来源

• GraphQL 官方：https://graphql.org/
• GraphQL Specification：https://spec.graphql.org/September2025/
• Meta Engineering, GraphQL: A data query language：https://engineering.fb.com/2015/09/14/core-infra/graphql-a-data-query-language/
• GraphQL Spec Repository：https://github.com/graphql/graphql-spec
• Postman 2025 State of the API：https://www.postman.com/state-of-api/2025/
• GitHub GraphQL API：https://docs.github.com/en/graphql