GraphQL API는 어떻게 캐싱하나요?

Question

IT Interview Practice · Accepted Answer

GraphQL 캐싱은 REST보다 어렵습니다. endpoint가 하나이고 요청이 대개 POST이므로 URL 기반 HTTP 캐싱이 기본으로는 동작하지 않기 때문입니다. 대신 세 개의 계층에서 캐싱합니다: **클라이언트**, **transport/CDN**, **서버**.

## 정규화된 클라이언트 캐시

Apollo Client와 Relay는 결과를 `__typename` + `id`를 key로 하는 **정규화된 캐시(normalized cache)**에 저장합니다. 모든 객체는 한 번만 저장됩니다; 같은 `User:1`을 참조하는 서로 다른 쿼리들은 이를 공유하므로, 한 엔티티를 갱신하는 mutation이 모든 뷰를 자동으로 새로 고칩니다.

```graphql
# Both queries write to the same normalized entry User:1 in the client cache
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } }  # author is also User:1
```

이것이 필드가 `id`를 반환해야 하는 이유입니다 — 캐시는 중복을 제거하기 위한 안정적인 key가 필요합니다.

## Persisted query + CDN

**Persisted query**는 쿼리 문자열을 해시로 대체합니다. 클라이언트는 긴 POST 본문 대신 짧은 해시를 보내고, 서버는 등록된 쿼리를 조회합니다.

```js
// Automatic Persisted Queries: first a tiny GET with just the hash
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> because it's a GET with a stable key, a CDN can cache the RESPONSE at the edge
```

읽기 쿼리를 캐시 가능한 GET으로 바꾸면 **CDN**이 이를 edge에서 서빙할 수 있고 payload도 줄어듭니다. `@cacheControl` 힌트(max-age, scope)를 통해 서버는 CDN과 Apollo 서버 캐시가 존중하는 필드별 TTL을 선언할 수 있습니다.

## 서버 측

쿼리 + 변수 + 인증 범위를 key로 하는 응답 캐시(예: Apollo의 것)는 resolver 재실행을 피합니다; DataLoader는 요청 단위 중복 제거를 담당합니다(별개의 문제입니다 — 요청 간 캐시가 아닙니다).

## 왜 중요한가

단일 endpoint/POST 설계는 순진한 HTTP 캐싱을 깨뜨리므로, 면접관은 **계층적인** 답을 듣고 싶어 합니다: 클라이언트의 정규화된 엔티티 캐시, CDN/edge 캐싱을 여는 persisted query + `@cacheControl`, 그리고 DataLoader가 어디에 들어맞는지(요청 간이 아니라 요청 단위).

정규화된 클라이언트 캐시

Persisted query + CDN

서버 측

왜 중요한가

관련 질문