[SWR] stale-while-revalidate

vercel에서 개발한 라이브러리인 SWR은 캐시 무효화 전략 중 하나인 stale-while-revalidate의 방법을 차용해 컴포넌트 별 데이터를 최신으로 유지한다.

stale-while-revalidate

When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.

HTTP 응답에 있는 경우, stale-when-revalidate Cache-Control 확장은 표시된 시간(초)까지 오래된 상태가 된 후, 캐시가 응답을 제공할 수 있음을 나타냅니다.

If a cached response is served stale due to the presence of this extension, the cache SHOULD attempt to revalidate it while still serving stale responses (i.e., without blocking).

이 확장으로 인해 캐시된 응답이 오래된 경우, 캐시는 오래된 응답(즉, 차단하지 않음)을 계속 제공하는 동안 응답의 재검증을 시도해야 합니다.

Note that "stale" implies that the response will have a non-zero Age header and a warning header, as per HTTP's requirements.

"stale"은 HTTP의 요구 사항에 따라 응답에 0이 아닌 Age 헤더와 경고 헤더가 있음을 의미합니다.

If delta-seconds passes without the cached entity being revalidated, it SHOULD NOT continue to be served stale, absent other information.

캐시된 엔티티의 유효성을 다시 검사하지 않고 델타 초가 경과한 경우 다른 정보가 없으면 오래된 엔티티가 계속 제공되어서는 안 됩니다.

HTTP RFC 5861 - 3.The stale-while-revalidate Cache-Control Extension with 파파고

무슨 소리인지 잘 모르겠지만, RFC 5861의 예시를 짧게 요약했다.

Cache-Control: max-age=600, stale-while-revalidate=30

위 코드가 헤더에 포함되어 있다면 캐시의 수명은 600초다. 수명이 지난 캐시는 stale해진다. 요청은 이후 30초 동안 현재 데이터가 최신인지 검증한다. 검증하는 동안 데이터에 변화가 없다면 해당 캐시는 실효되어 요청을 차단한다.

SWR은 이러한 메커니즘으로 먼저 캐시(스태일)로부터 데이터를 반환한 후, fetch 요청(재검증)을 하고, 최종적으로 최신화된 데이터를 가져온다.

Server state vs UI state

SWR를 비롯한 상태 관리 라이브러리를 사용하는 이유는 Server state와 UI state를 분리하기 위함이다.

UI state는 비영구적이며 브라우저 로컬에서 관리되는 상태이다. 페이지 로드시 재설정되고 대부분 동기적으로 데이터를 로드한다. 데이터 변경이 즉각적이며 새로운 상태가 어떨지 사용자가 알 수 있다.

반면, Server state는 서버에 영구적으로 저장되는 상태를 말한다. 비동기적으로 동작하며, 데이터 로딩에 시간이 걸린다. 로드에 성공했는지 실패했는지도 모른다. 무엇보다 제 3의 사용자가 데이터를 변경했을 때 기존 사용자는 가져온 데이터가 최신인지 아닌지 알 수 없다.

참고 : State Management: Separation of Concerns