# Section4
1. 앱 라우터의 데이터 페칭
데이터 페칭
앱 라우터에서 데이터 페칭은 각각의 컴포넌트에서 진행된다
(Next.js의 공식문서에 따르면 데이터는 필요한 곳에서 직접 불러오라고 쓰여있다)
컴포넌트 자체에 async 키워드를 붙여 비동기 함수로 만들고
해당 함수 내부에서 await 키워드와 함께 데이터를 불러오는 로직을 작성할 수 있다
(await : 기존의 getServerSideProps, getStaticProps 를 대체)
만약 하나의 파일에서 여러개의 fetch가 필요한 경우에는
비동기 함수를 따로 작성하여 사용하는 것이 좋다
백엔드 서버 가동하고 src/app/(with-searchbar)/search/page.tsx 에서 진행
① 비동기 함수 설정 async ~ await
② 컴포넌트에서 호출하기
그런데❗
fetch 할 때마다 중복되는 url을 하나의 변수로 설정해놓으면 더 편리하지 않을까?
환경변수 설정하기
프로젝트의 최상단에 .env 파일 생성
환경변수로 등록하려는 url 입력
NEXT_PUBLIC 이라는 접두사를 붙여야만 클라이언트 컴포넌트에서 사용할 수 있다
만약, NEXT_PUBLIC이 붙지 않으면 Next가 자동으로 환경변수를 서버측에서만 작동할 수 있게 Private로 설정해버린다
환경변수로 fetch url 변경
2. 데이터 캐시
- fetch 메서드를 활용해 불러온 데이터를 Next 서버에서 보관하는 기능
- 영구적으로 데이터를 보관하거나, 특정 시간을 주기로 갱신 시킬 수 있다
- 총 4개의 캐시옵션이 존재하는데 fetch 메서드의 두번째 인수로 작성한다
- 아무런 옵션을 작성하지 않으면 기본값으로 캐싱을 하지 않는 것으로 설정된다
(14버전 까지는 기본적으로 캐싱O, 15버전 부터는 기본적으로 캐싱X)
⇒ 불필요한 데이터 요청의 수를 줄여서 웹 서비스의 성능을 크게 개선할 수 있다
캐시 과정을 확인해보려면 next.config.mjs 설정을 먼저 변경하고 진행한다
캐시 옵션
1. { cache : 'no-store' }
데이터 페칭의 결과를 저장하지 않는 옵션
캐싱을 아예 하지 않도록 설정하는 옵션
실습
2. { cache : 'force-cache' }
요청 결과를 무조건 캐싱함
처음 호출 된 이후에는 다시는 호출되지 않음
HIT : 캐싱된 데이터를 찾아냄
실습
보관된 캐시 데이터 확인하기
3. { next : { revalidate : n } }
특정 시간을 주기로 캐시를 업데이트
마치 Page Router의 ISR 방식과 유사
새로고침시 n초 간격으로 캐시가 업데이트 된다
STALE : 기한이 지난 데이터
4. { next : { tags : ['a'] } }
On-Demand Revalidate
요청이 들어왔을 대 데이터를 최신화 함
이후에 추가적인 개념을 학습한 뒤 다시 살펴볼 예정
3. 리퀘스트 메모이제이션 (Request Memoization)
- 자동으로 데이터 페칭을 최적화해준다
- 중복된 API 요청을 하나의 요청으로 자동으로 합쳐준다
- App Router에서 서버 컴포넌트의 도입으로
데이터를 페칭하는 패턴이 변경되어 리퀘스트 메모이제이션을 사용한다
중복요청 제거
동일 API 3번 요청
→ 첫번째 요청시 리퀘스트 메모이제이션에 SET 되고,
→ 이후 요청시 리퀘스트 메모이제이션에서 데이터를 찾아온다
🚨리퀘스트 메모이제이션 vs 데이터 캐시
EX )
메인페이지에 도서 목록과 Footer가 렌더링된다
도서 목록을 나타내기 위해 book API를 요청하고
Footer에는 도서의 개수를 나타내기 위해 book API를 요청한다
즉, 한 페이지에서 동일한 API를 요청하고 있기 때문에 API 요청이 중복되는 상황이 발생한다
이런 경우에 리퀘스트 메모이제이션이 작동한다
두개의 book API 요청을 → 하나의 요청으로 합쳐 자동으로 데이터 페칭을 최적화해준다
