서버 컴포넌트 데이터 패칭

다음과 같이 작업하면 예전 처럼 Props나 ContextApi를 사용해서 힘겹게 넘겨 줄 필요 없이 필요한 부분을 꺼내 쓰면 된다.

서버 컴포넌트에 async를 붙여서 비동기 함수를 만들어 내부에서 직접 데이터를 패칭해 올 수 있다.

데이터 캐시

불필요한 데이터 요청의 수를 줄여서 웹 서비스의 성능을 크게 개선 할 수 있음

간단한 데이터 캐시 종류

해당 fetch 매서드는 axios와 같은 라이브러리에서는 사용을 못하고 fetch에서 적용 가능하다

cache:"no-store"

데이터 캐시가 일어나지 않는다.
즉 cache를 적용하지 않는 상태랑 동일하게 작동한다
(Next14 이전 버전은 기본으로 무조건 캐싱하도록 설정이 되어 있다.)

cache:"force-cache"

먼저 데이터 캐시에서 저장된 정보를 찾아보고 없으면 miss로 발생한다.

-> 백엔드에서 데이터를 요청하고 다음부턴 요청하지 않게 한다(즉 데이터 캐시 안에 저장한다)


만약 데이터가 있으면 hit로 실제 백엔드 서버에 데이터 요청을 하지 않는다

next:{revalidate:3}

캐시 데이터를 3초 주기로 자동으로 next 서버를 업데이트 하게 된다.
-> 3초 전에는 force-cache와 동일하고 3초 후에 해당 데이터가 상했다로 받아들여서 set을 통해 벡엔드에서 다시 데이터를 요청 후 그후는 동일하다.

Request Memoization

Miss : 리퀘스트 메모이제이션에 없음
Set: 리퀘스트 메모이제이션에 저장
Hit: 리퀘스트 메모이제이션에 존재함으로 백엔드 서버에 전달 하지 않음

다음과 같이 request memoization에서 해당 api 중복 여부를 확인한다.

요청을 기억한다라는 뜻으로 여러 개의 컴포넌트에서 발생하는 요청들 중 중복이 제거된 요청들로 추려서(캐싱해서) 한번만 요청 할 수 있도록 (중복되게 요청하지 않도록) 자동으로 캐싱하는 기능이다.

Request memoization을 사용하는 이유

하나의 페이지를 렌더링 하는 동안에 중복된 API 요청을 캐싱하기 위해 존재한다.
(렌더링이 종료되면 모든 캐시가 소멸된다.)

Full Route Cache

Next 서버 측에서 빌드 타임에 특정 페이지의 렌더링 결과를 캐싱하는 기능이다.

Dynamic Page로 설정되는 기준

특정 페이지가 접속 요청을 받을 때 마다 매번 변화가 생기거나, 데이터가 달라지는 경우

위와 같이 캐쉬가 no-store로 설정되거나 캐쉬가 설정되지 않았을 때

Dynamic Page,Static Page 구분 방법

Full Route Cache를 ISR 처럼 revaluate가 가능