Next.js에서 fetch와 tanstack-query 똑똑하게 쓰기

안녕하세요 IT 비즈니스 파트너 똑똑한개발자에서 프론트엔드 개발을 하고 있는 손은경입니다 ☺️

이전 포스팅에서는 Next.js에서 data fetching과 caching에 대해서 다뤘습니다. 이번 글 에서는 Next.js 에서 데이터 페칭 시 고민한 문제들에 대해서 이야기해보겠습니다.

Next.js에서 fetch와 tanstack-query 효율적으로 사용하는 방법

App Router를 사용하면서 기존에 사용하던 tanstack-query를 제거하고 오직 fetch 만을 사용하여 데이터 캐시 관리를 했습니다.

1. fetch의 기능이 강력하므로 tanstack-query가 꼭 필요하지 않았습니다.

2. tanstack-query 공식 문서에서 권장사항을 발견했습니다. (본문 참고)

🤔 공식 문서를 바탕으로 라이브러리 도움 없이 fetch를 사용하다가 다음과 같은 고민이 생겼습니다.

1. API 호출 비용을 최대한 줄이면서 유저에게 빠르게 데이터를 보여줄 수 있는 방법이 있을까?

• 이전 글에서 언급한 대로, 개인화된 요청은 원격 서버에 캐싱 되어서는 안 됩니다. 따라서 fetch를 사용할 때 no-store 옵션을 설정합니다. 이 경우, 새로고침 및 라우트 캐시가 만료될 때 마다 API 호출이 발생하므로 client-side에서 tanstack-query를 사용하여 브라우저 메모리에 개인화된 요청에 대한 응답을 캐시 하고 queryKey와 staleTime으로 캐시를 관리합니다.

• 개인화 되지 않은 요청은 server-side에서 force-cache 옵션을 사용하여 API를 호출하고, 적절한 방법을 통해 갱신합니다.

1번 고민에 대한 결과를 정리하면, 개인화 된 요청은 검색 엔진에 노출될 필요가 없으므로 client-side에서 tanstack-query로 요청 후 캐시를 관리합니다.

그 반대의 경우 server-side에서 fetch 하면 첫번째 요청 시 데이터가 원격 서버에 캐싱되며 Suspense의 fallback 을 이용하여 유저에게 데이터를 가져오는 중임을 알립니다. 두 가지 방법을 적절히 섞어 사용하면 API 호출 비용을 줄이고, 유저에게 빠르게 데이터를 보여줄 수 있습니다.

이 때, 2번의 고민이 발생합니다.

2. server-side에서 fetching 한 데이터를 사용하는 곳까지 props drilling 하는 것을 최소화 할 수 있는 방법이 있을까?

props drilling방식으로 데이터를 전달하면 상위 컴포넌트가 변경되면 하위 컴포넌트 까지 변경해야 하는 문제가 있습니다. 이는 유지보수 관점에서 좋지 않습니다.

이에 이어지는 내용은 이미지 추가 첨부가 필요하여, 똑똑한개발자 팀블로그에서 이어서 작성하도록 하겠습니다! 아래 링크에서 바로 확인하실 수 있어요.