你听说过 GraphQL 吗？这种最早由 Facebook（现 Meta）创建的 API 查询语言已经蓬勃发展成了一个庞大的生态系统。阅读以下文章，了解我们为什么有必要拥抱这种新的 API 范式。
软件工程项目复杂性带来新挑战
API Schema
在管理传统 REST API 时，通常需要借助 OpenAPI 或 Postman 这样的工具来管理 API Schema。这种方式是一种独立于 API 本身的定义方式，是否提供以及如何正确完成这些描述文件，完全依赖于开发者的认知和水平。
在生成 API Schema 的过程中，我们常常遭遇复杂的工具链和容易出错的生成物，这让开发者感到烦恼。提供包括数据模型、API 描述、文档和示例的完整定义并非易事，而展示 OpenAPI 需要使用 Swagger UI 等方式，也需要投入额外工作。
API 协议
在传统 REST API 查询或提交数据时，HTTP 的请求-响应模型一直表现良好。然而，获取时常变化的数据则需要考虑长轮询或 WebSocket 等方式。尽管这些方法可行，但关于我们在效率和控制成本之间的谨慎平衡，目前没有一种开箱即用的机制可以很好地兼顾这两种模式。
复杂场景的挑战
过去，开发者只需提供一个基于 API 的 Web 页面供用户在浏览器中使用，直接通过 HTML 展示数据。然后，随着移动时代的到来，开发者需要为 Android 和 iOS 平台提供原生应用。这些应用有不同的用户群和使用习惯，信息密度也不尽相同。开发者很难通过一套单一的 API 为所有平台提供支持，每个平台的不同数据和交互需求都需要特定的 API。在服务端应用中，开发者还需面对逐渐膨胀的数据源，例如关系型数据库或 Redis 缓存。如何正确管理数据的持久化和缓存，并为客户端提供查询，也是一个巨大的挑战。
GraphQL 助力 API 开发
GraphQL 有助于应对这些复杂性。它提供了一个统一的 API Schema，可以通过 Schema-first 或 Code-first 的方式编写数据模型和 API 接口的描述，确保了 API 实现和定义的一致性和正确性。GraphQL 支持原生数据变更订阅能力，通过 WebSocket 通道实现数据变更的实时推送。在 HTTP 协议和 JSON 编码格式的基础上，GraphQL 的请求流量对代理服务器非常友好。它还提供了按需查询和聚合数据的能力，允许不同平台的调用者使用同一套 GraphQL API 并获取所需数据，避免了强制获取全部数据的情况。GraphQL 还具有丰富的生态系统和诸多扩展，如 GraphQL Relay 规范、GraphQL federation 和 GraphiQL 工具等。
总结
总体而言，GraphQL 是一种比 REST 更先进的思想，简化了 API 定义的复杂工作流，使得 API 的开发更加灵活。在工程方面，更多的自动化工具简化了 API 开发中的重复性模板代码工作，使得开发者可以更专注于应用本身。相比 REST API，GraphQL 允许开发者渐进式的改进其 API，无论是添加新 API 或是新增字段，对现有用户是无感知的，无需划分版本并打断使用旧版本 API 的用户。现在，已经有很多平台提供 GraphQL API，如 Meta 在其移动应用中使用的 GraphQL API、GitHub 和 Shopify 直接提供供开发者调用的 GraphQL API。