如何缓存一个 GraphQL API？

Question

如何缓存一个 GraphQL API？

IT Interview Practice · Accepted Answer

缓存 GraphQL 比 REST 更难，因为只有一个 endpoint，而且请求通常是 POST，所以基于 URL 的 HTTP 缓存开箱即用行不通。你转而在三层做缓存：**客户端**、**传输层/CDN** 和 **服务端**。

## 归一化的客户端缓存

Apollo Client 和 Relay 把结果存进一个以 `__typename` + `id` 为键的**归一化缓存（normalized cache）**。每个对象只存一份；引用同一个 `User:1` 的不同查询会共享它，因此更新某个实体的 mutation 会自动刷新每个视图。

```graphql
# 两个查询都写入客户端缓存中同一个归一化条目 User:1
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } }  # author 也是 User:1
```

这就是为什么字段应当返回 `id`——缓存需要一个稳定的键来去重。

## 持久化查询 + CDN

**持久化查询（persisted queries）** 用一个 hash 取代查询字符串。客户端发送一个短 hash 而非冗长的 POST 体；服务器据此查出已注册的查询。

```js
// 自动持久化查询：先发一个只带 hash 的小 GET
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> 因为它是带稳定键的 GET，CDN 可以在边缘缓存这个响应
```

把读查询变成可缓存的 GET，让 **CDN** 能在边缘提供它们，并缩小载荷。`@cacheControl` 提示（max-age、scope）让服务器为每个字段声明 TTL，CDN 和 Apollo 服务端缓存都会遵守。

## 服务端

一个以 查询 + 变量 + 认证范围 为键的响应缓存（例如 Apollo 的）可以避免重跑 resolver；DataLoader 处理请求内的去重（这是另一回事——它不是跨请求的缓存）。

## 为什么这很重要

单 endpoint / POST 的设计破坏了朴素的 HTTP 缓存，所以面试官想听到**分层**的答案：客户端上的归一化实体缓存，持久化查询 + `@cacheControl` 以解锁 CDN/边缘缓存，以及 DataLoader 的定位（按请求，而非跨请求）。

归一化的客户端缓存

相关问题

持久化查询 + CDN

服务端

为什么这很重要