缓存
提供对象标识符，以便客户端构建强大的缓存
在基于端点的 API 中，客户端可以使用 HTTP 缓存 来避免重复获取资源，并识别两个资源是否相同。在这些 API 中，URL 是客户端可用来构建缓存的全局唯一标识符。
在 GraphQL 中，没有类似于 URL 的原语来为给定对象提供这种全局唯一标识符。因此，API 公开这样一个标识符是最佳实践，供客户端使用，作为实现某些类型缓存的前提条件。
全局唯一 ID
在 Schema 中标准化对象的识别方式
实现此目的的一种可能模式是保留一个字段（如 id）作为全局唯一标识符。本套文档中贯穿使用的示例 Schema 就采用了这种方法
这对于客户端开发人员来说是一个强大的工具。正如基于资源的 API 的 URL 提供全局唯一键一样，该系统中的 id 字段也提供了一个全局唯一键。
如果后端使用 UUID 之类的东西作为标识符，那么公开这个全局唯一 ID 可能会非常简单！如果后端尚未为每个对象提供全局唯一 ID，则 GraphQL 层可能必须构造一个。通常，这就像在 ID 后追加类型名称并将其作为标识符一样简单。然后，服务器可以通过 Base64 编码使该 ID 变得不透明（Opaque）。
可选地，当使用全局对象识别时，此 ID 可用于配合 node 模式工作。
与现有 API 的兼容性
为此目的使用 id 字段的一个担忧是，使用 GraphQL API 的客户端如何与现有 API 配合工作。例如，如果我们现有的 API 接受特定类型的 ID，但我们的 GraphQL API 使用全局唯一 ID，那么同时使用两者可能会很棘手。
在这些情况下，GraphQL API 可以在单独的字段中公开之前 API 的 ID。这让我们可以兼顾两者的优点
- GraphQL 客户端可以继续依靠一致的机制来获取全局唯一 ID。
- 需要使用我们之前 API 的客户端也可以从对象中获取
previousApiId并使用它。
替代方案
虽然全局唯一 ID 在过去被证明是一种强大的模式，但它们并不是唯一可以使用的模式，也不适合所有情况。客户端需要的关键功能是为其缓存派生全局唯一标识符的能力。虽然让服务器派生该 ID 可以简化客户端，但客户端也可以自行派生标识符。这可以简单到将对象类型（通过 __typename 查询）与某些类型唯一的标识符相结合。
此外，如果用 GraphQL API 替换现有 API，那么如果 GraphQL 中的所有字段都相同，唯独 id 变成了全局唯一的，这可能会令人困惑。这是人们可能选择不使用 id 作为全局唯一字段的另一个原因。
总结
回顾一下这些关于在 GraphQL API 中使用缓存的建议
- 为对象类型定义全局唯一 ID 字段可以促进各种类型的缓存
性能
获取提高 GraphQL 性能的实用技巧 —— 从防止 N+1 问题到监控和压缩。
