¿Cómo se cachea una API GraphQL?

Question

IT Interview Practice · Accepted Answer

Cachear GraphQL es más difícil que REST porque hay un único endpoint y las peticiones suelen ser POST, por lo que el caching HTTP basado en URL no funciona de forma inmediata. En su lugar, cacheas en tres capas: **cliente**, **transporte/CDN** y **servidor**.

## Cache normalizada en el cliente

Apollo Client y Relay guardan los resultados en una **cache normalizada** con clave `__typename` + `id`. Cada objeto se almacena una sola vez; distintas queries que referencian el mismo `User:1` lo comparten, así que una mutation que actualiza una entidad refresca automáticamente todas las vistas.

```graphql
# Ambas queries escriben en la misma entrada normalizada User:1 de la cache del cliente
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } }  # author también es User:1
```

Por esto los campos deberían devolver `id`: la cache necesita una clave estable para deduplicar.

## Persisted queries + CDN

Las **persisted queries** sustituyen la cadena de la consulta por un hash. El cliente envía un hash corto en lugar de un cuerpo POST largo; el servidor busca la consulta registrada.

```js
// Automatic Persisted Queries: primero un GET diminuto solo con el hash
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> al ser un GET con una clave estable, un CDN puede cachear la RESPUESTA en el edge
```

Convertir las queries de lectura en GETs cacheables permite que un **CDN** las sirva en el edge y reduce el tamaño de los payloads. Las directivas `@cacheControl` (max-age, scope) permiten que el servidor declare TTLs por campo que el CDN y la cache del servidor Apollo respetan.

## Del lado del servidor

Una response cache (p. ej. la de Apollo) con clave query + variables + scope de auth evita re-ejecutar los resolvers; DataLoader se encarga de la deduplicación por petición (una preocupación distinta: no es una cache entre peticiones).

## Por qué es importante

El diseño de endpoint único/POST rompe el caching HTTP ingenuo, así que los entrevistadores quieren oír la respuesta **por capas**: cache de entidades normalizada en el cliente, persisted queries + `@cacheControl` para habilitar el caching en CDN/edge, y dónde encaja DataLoader (por petición, no entre peticiones).

Cache normalizada en el cliente

Persisted queries + CDN

Del lado del servidor

Por qué es importante

Preguntas relacionadas