🔖 데이터 패칭
Page Router에서의 데이터패칭에서는 SSR,SSG,ISR 방식 등으로 서버측에서 데이터를 불러와 브라우저 측으로 한번 더 넘겼어야했다.
- 사진처럼 Props를 하위 컴포넌트까지 내려주는 프롭 드릴링이 발생 - > 비효율적
App Router에서는 서버컴포넌트가 존재하기 때문에 위문제를 겪지 않아도된다
- 클라이언트 컴포넌트에서 async 비동기 함수는 충돌을 일으킬 수 있기 때문에 사용을 안하지만, 서버컴포넌트에 선언이 가능하다 !
- async 비동기 함수를 사용하여 데이터패칭
🔖 데이터 캐시
: fetch 메서드를 활용해 불러온 데이터를 Next 서버에서 보관하는 기능
영구적으로 데이터를 보관하거나, 특정시간을 주기로 갱신 가능
✅ 불필요한 데이터 요청의 수를 줄여서 웹 서비스의 성능을 크게 새선할 수 있음.
- fetch 메서드 두번째 인수로 설정해주며, 오직 fetch 메서드에서만 사용가능하다.
캐시옵션
1. ` { cache : "no-store"} ` : 캐시안함( 기본값)
2. ` { cache : "force-cache"} ` : 무조건 캐싱, 한번 호출되면 그 뒤로 호출 안함
3. ` { cache : {revalidate:3 } } ` : 특정 시간마다 재 캐싱
4. ` { cache : tags : ['a'] } ` : 요청이 들어올 때만 캐시를 함.
🔖 리퀘스트 메모이제이션
- Request Memoization이란, "요청을 기억한다"는 뜻으로 같은 API 요청을 반복적으로 호출하지 않도록 방지하는 기능이다.
- 여러개의 컴포넌트에서 발생하는 동일한 요청에 대해 데이터를 캐싱 후 재사용하여, 자동으로 데이터 페칭을 최적화시켜 불필요한 네트워크 트래픽을 줄임.
- 페이지 렌더링 중에만 적용되며, 렌더링이 종료되면 캐시가 소멸된다.
- ✅ 따로 코드를 작성하지 않아도 자동으로 합쳐진다는 것
① 첫 번째 요청
처음 API 요청이 발생했을 때 Request Memoization에는 아무 데이터도 캐싱되지 않은 상태이다.
요청 결과는 MISS로 판정되고, 백엔드 서버에 요청이 전달된다.
응답 데이터를 받은 후, Request Memoization에 해당 데이터를 SET(저장)한다.
② 중복된 요청
동일한 API 요청이 반복될 경우 Request Memoization에 저장된 데이터를 먼저 확인한다.
캐싱된 데이터가 있다면(HIT), 데이터를 다시 요청하지 않고 캐싱된 데이터를 그대로 사용해 페이지를 렌더링 한다. (이런 경우에는 요청을 아예 발송하지 않는다)
③ 렌더링 종료
페이지 렌더링 종료 후 Request Memoization에 저장된 데이터는 자동으로 삭제된다.
새로고침이나 새로운 요청이 들어오면, 다시 MISS 상태로 돌아간다.
🔖 리퀘스트 메모이제이션 필요성
중복된 API요청이야 안 보내면 그만인 거 아닌가? 라고 생각할 수 있는데
굳이 Next가 이런 추가적인 기능까지 제공해 주고 있는 이유가 무엇일까?
서버 컴포넌트의 도입으로 인해서 이제는 데이터를 페칭하는 패턴이 변화했기 때문이다.
Page Router버전의 Next앱은 서버 측에서 데이터를 페칭해 오려면 getServerSideProps나 getStaticProps같은 서버 측에서만 실행되는 함수를 통해서 데이터를 불러오고,
페이지 컴포넌트에게 데이터들을 props로 넘겨주는 방식을 사용했지만,
App Router에서 도입된 서버 컴포넌트는 컴포넌트별로 데이터를 직접 페칭하는 방식을 사용한다.
이 방식은 컴포넌트가 독립적으로 데이터를 처리하도록 만들어 개발 편의성을 높였지만, 아래와 같은 문제가 발생할 수 있다.
서로 다른 컴포넌트가 동일한 데이터를 중복 요청하는 경우.
중복된 데이터 요청이 많아질수록, 불필요한 네트워크 비용이 발생.
'🌃 Next.js > 🔜 next.js-study' 카테고리의 다른 글
| [Next.js] 6. 페이지 캐싱 (0) | 2025.03.27 |
|---|---|
| [Next.js] 4. 페이지 라우팅 설정하기 (0) | 2025.03.18 |