Skip to main content
Sonamu의 @api 데코레이터에 cacheControl 옵션을 추가하여 API 응답에 Cache-Control 헤더를 설정할 수 있습니다.

기본 사용법

@api 데코레이터에 추가

결과:

설정 방법

가장 간단한 방법
사용 가능한 프리셋:
  • noStore: 캐시 금지
  • noCache: 매번 재검증
  • shortLived: 1분
  • mediumLived: 5분
  • longLived: 1시간
  • private: 개인화 데이터

우선순위

Cache-Control 설정은 다음 순서로 적용됩니다:
  1. @api 데코레이터의 cacheControl (가장 우선)
  2. cacheControlHandler 반환값
  3. 기본값 (Cache-Control 헤더 없음)

예시

결과: mediumLived 적용 (데코레이터가 우선)

HTTP 메서드별 전략

GET 요청

조회 API는 캐싱 가능합니다.

POST, PUT, DELETE 요청

Mutation 요청은 캐싱하면 안 됩니다.
Mutation 요청에 캐싱을 설정하면 안 되는 이유:
  • 같은 POST 요청을 여러 번 보내면 중복 생성 발생
  • 브라우저가 이전 응답을 재사용 → 실제로는 생성되지 않은 것처럼 보임

데이터 특성별 전략

공개 데이터 (public)

모든 사용자에게 동일한 응답입니다.
특징:
  • 브라우저 + CDN에서 캐싱
  • 네트워크 트래픽 최소화
  • 서버 부하 감소

개인 데이터 (private)

사용자별로 다른 응답입니다.
특징:
  • 브라우저에만 캐싱 (CDN 불가)
  • 다른 사용자에게 노출 방지

민감한 데이터 (no-store)

캐싱하면 안 되는 데이터입니다.

실전 예제

1. 전자상거래 API

2. 블로그 API

3. 사용자 API

CDN 최적화

s-maxage 활용

브라우저와 CDN에 다른 TTL을 적용할 수 있습니다.
효과:
  • 브라우저: 1분마다 CDN에 요청
  • CDN: 5분마다 서버에 요청
  • 서버 부하 최소화

Stale-While-Revalidate

CDN에서 Stale 응답을 즉시 반환하면서 백그라운드 갱신:
CloudFront 지원: AWS CloudFront는 stale-while-revalidate를 지원합니다.

Vary 헤더

요청 헤더에 따라 다른 캐시를 사용합니다.
결과:

전역 핸들러

모든 API에 일괄적으로 Cache-Control을 적용할 수 있습니다.

API 객체 활용

BentoCache와 함께 사용

서버 캐시와 HTTP 캐시를 조합하면 최대 성능을 얻을 수 있습니다.
효과:
  1. 0~60초: 브라우저 캐시 (서버 요청 없음)
  2. 60초~10분: 서버 요청하지만 BentoCache 사용 (DB 조회 없음)
  3. 10분 이후: DB 조회 → 다시 캐싱

주의사항

API Cache-Control 사용 시 주의사항:
  1. GET만 캐싱: POST, PUT, DELETE는 반드시 noStore 사용
  2. 개인 데이터는 private: CDN 캐싱 방지
  3. 자주 변경되는 데이터는 짧은 TTL: 오래된 데이터 방지
  4. 인증 필요한 API는 조심: Authorization 헤더 고려

다음 단계

Cache-Control이란?

HTTP 캐싱 기본 개념

Cache Presets

사전 정의된 캐시 설정

SSR에서 사용하기

SSR 페이지에 Cache-Control 적용