GraphQL：API的查询语言

GraphQL：精确请求你所需的数据

你是否曾使用过返回过多数据或过少数据的API？这正是GraphQL旨在解决的问题。GraphQL不再由服务器决定发送哪些数据，而是由客户端精确请求所需内容，并只获取这些内容。这就像点菜而不是接受固定的套餐。

GraphQL的工作原理

GraphQL的核心是模式——一份描述所有可用数据及其连接方式的说明。模式是强类型的，意味着每条数据都有特定的类型：字符串、数字、布尔值，或者更复杂的类型如对象和列表。这个模式充当客户端和服务器之间的契约。

客户端发送查询来精确描述它们想要的内容。例如，一个查询可能请求用户的姓名和电子邮件，以及该用户最近的订单。服务器会返回一个与查询形状相匹配的JSON对象——没有多余的数据，也没有缺失的字段。这消除了过度获取（获取不需要的数据）和不足获取（需要多次请求才能获取所有需要的数据）的问题。

查询、变更和订阅

GraphQL有三种操作类型。查询用于读取数据——相当于GET请求。变更用于写入数据——创建、更新或删除资源。订阅用于实时更新——每当有变化时，服务器会向客户端推送数据，比如新通知或实时聊天消息。

解析器：如何获取数据

在服务器端，模式中的每个字段都有一个解析器函数，它知道如何获取该数据。解析器可以调用数据库、外部API，或者即时计算值。它们接收父对象、参数、上下文（通常包含身份验证和数据库连接）以及关于查询的信息。GraphQL会选择性调用解析器——只运行实际请求的字段的解析器。

一个常见的挑战是N+1问题，即获取一个项目列表，然后为每个项目获取一个相关字段会导致大量数据库查询。解决方案是DataLoader，它批处理和缓存请求，使得多个需要相同数据的解析器可以共享一个数据库查询。

联邦：组合多个服务

对于大型组织，单一的GraphQL模式可能会变得难以管理。联邦允许你将模式拆分到多个服务中，每个服务负责自己的领域。一个网关将它们组合成一个统一的图，供客户端交互。这样，独立团队可以拥有自己部分的API，同时为消费者呈现一致的体验。

GraphQL vs REST：何时使用各自

GraphQL在以下情况下表现出色：你有复杂的数据关系、多个客户端有不同的需求，并且希望快速迭代而不需要版本控制。REST更简单、更成熟，具有原生缓存、更广泛的工具支持和更简单的学习曲线。对于许多项目，最好的方法是先使用REST，当复杂性证明需要时，再迁移到GraphQL。

GraphQL不是REST的替代品——它是针对不同问题的不同工具。理解两者可以让你在每种情况下选择正确的工具。