nextjs의 time based revalidate 는 어떻게 이루어지는걸까?

 

서버 컴포넌트에서 데이터를 GET할 것이다.

ravalidate time을 설정했는데 예상과 달리 동작할 것이다.

이를 위해선 nextjs의 캐시 체계와 로직을 알아야한다.

 

1. 라우터 캐시

클라이언트 사이드에서 적용되는 캐시이다.

이를 통해 유저는 라우터 캐시가 HIT되는 경로로 이동하면 매우 빠르게 페이지를 볼 수 있다.

 

2. 풀 라우터 캐시

서버 사이드에서 적용되는 캐시이다.

어떤 경로의 랜더링된 결과를 캐시한다.

라우터 캐시와의 차이점은 풀 라우터 캐시는 RSC payload와 HTML을 캐싱한다.

라우터 캐시는 이와 달리 RSC payload를 캐싱한다.

 

3. 데이터 캐시

서버의 요청 및 배포를 통해 가져온 데이터에 적용되는 캐시이다.

 

이제 유저가 페이지에 입장하는 상황을 시뮬레이션 해보자.

이 페이지에선 data resource로 부터 data를 GET하는 서버 컴포넌트가 포함된다.

 

1. 클라이언트사이드 라우터 캐시 검사

HIT되면 라우터 캐시로 캐시된 페이지를 보여주고 끝난다.

MISS되면 캐시를 세팅하고 다음 단계로 진행한다.

 

2. 서버사이드 풀 라우터 캐시 검사

HIT되면 풀 라우터 캐시된 페이지를 보여준다.

MISS라면 해당 페이지의 RSC payload와 HTML을 만들어낸다.

풀 라우터 캐시가 HIT이든 MISS든 상관없이 3번 단계로 진행한다.

 

3. 데이터 캐시 검사

데이터를 요청한 시간 텀이 revalidate time을 지나지 않았다면, cache는 HIT이다. 이 말은 데이터가 바뀌지 않았단 말이므로, 캐시된 페이지를 보여줄 것이다.

만약에 stale/miss인 상황(revalidate time이 지난 상황)이라면, 유저가 해당 캐시 상태를 경험한 첫번째 유저라면 역시나 캐시된 페이지를 보여준다.

하지만 서버 백그라운드에선 다시 fetching한 뒤 fresh한 data를 이용해 새 페이지를 빌드한다.

이제 다른 유저는 해당 페이지에 들어가면 새로운 데이터로 채워진 페이지를 볼 수 있다.

자신은 라우터 캐시가 MISS라면 새로운 데이터로 채워진 페이지를 볼 수 있다.

 

이는 매우 간단한 상황을 시뮬레이션 한 것이다.

개념을 잡기위해 풀 라우터 캐시와 데이터 캐시가 서버사이드 캐시라는 것을 이해해야한다.