서론
next13은 React Server Component(이하, RSC)을 중심으로 app router라는 큰 변화를 가지고 왔습니다.
RSC과 server-action의 등장으로 인해 이젠 서버사이드 데이터 패칭의 범위가 확 늘어났습니다. 더불어 이런 서버사이드 요청에 대한 캐싱을 지원하기에 그럼 이제 react-query는 next-js에서 필요없을까? 하는 생각을 하게 됩니다.
결론 부터 말하지만 역할은 축소됐지만 여전히 필요하다라고 말씀드리고 싶습니다.
react-query는 클라이언트의 요청 서버 사이드의 요청은 next.js에서 처리할테니까요
이 부분에 대해서 next.js의 data-fetching 파트에서도 다음과 같이 설명하고 있습니다
swr 혹은 react-query를 이용해 클라이언트에서 데이터를 가지고 올 수 있다.
이런 라이브러리는 요청, 캐싱,재검증 등에 대한 자체적 API를 제공한다.
즉 경우에 따라 RSC,client, route handler라는 데이터 요청 케이스가 나눠졌다고 볼 수 있습니다.
각각의 경우가 적합한 상황에 대해서 알아보도록 하겠습니다.
데이터 요청 케이스
1. RSC
- 초기 페이지 로드시 프리패칭
- SSR, SEO가 중요한 콘텐츠
- 데이터베이스에 직접 접근해야 하는 경우
- 대용량 데이터 처리
2. Client
- 사용자 상호작용에 따라 동적으로 데이터를 가지고 오는 경우(무한스크롤)
- 실시간 업데이트가 필요한 경우
- 클라이언트에 따라 데이터 요청이 달라지는 경우
3. Route Handler
- API요청의 프록시 역할이 필요한 경우
- 복잡한 인증이나 권한, 시크릿키를 이용한 요청이 필요한 경우
- 여러 외부 API를 조합해야 하는경우
위와 같이 나눠볼 수 있을 것 같습니다.
한가지 추가적인 고민은 Route handler인데 모든 클라이언트 요청을 route handler에 위임하게 되면 일단 모든 요청을 nextjs에 위임할 수 있게 됩니다. 하지만 이 방법은 서버의 부하 증가로 추가적 인프라 구성이 필요하기 때문에 보안등의 이유로 서버 사이드 요청이 필요한 경우에 제한적 사용이 적절하다고 판단했습니다.
It also means you need to have the infrastructure to handle the additional server load
you-might-not-need-react-query
결론
react-query의 메인 개발자인 tkdodo는 you-might-not-need-react-query에서 현 시점의 next.js에서는 react-query와의 통합을 통해 상호 보완할 수 있다고 말합니다. Server Rendering에서 처럼 RSC를 프리패칭 레이어로 활용하고 클라이언트에서는 무한 스크롤, 인터벌 요청등의 상호작용 기반의 요청이나 개인화된 정보를 요청하는 용도로 말이죠. 해당 블로그 글 본문에서 말하는 하이브리드식 접근 방식입니다. (물론 이는 과도기적 접근방식으로 RSC의 발전에 따라 언제든 뒤집힐 수 있습니다)
반대로 일부 react-query는 RSC로 옮겨지지게 될 것 같습니다 예를 들면 staleTime: Infinity 옵션을 넣는 쿼리들이요.
참고
'react' 카테고리의 다른 글
[Nextjs] 다국어(i18n, internationalization) 적용하기 (0) | 2024.07.19 |
---|---|
[설계] 격리된 컴포넌트간의 통신 설계 (feat. Eventbus) (0) | 2024.06.28 |
[설계] 의존성 역전으로 변경에 유연한 설계하기 (0) | 2024.06.26 |
[설계] Compound Pattern으로 변경에 유연한 컴포넌트 설계하기 (0) | 2024.06.24 |
실무에서 가장 많이 실수하는 useEffect 사례 (0) | 2024.06.23 |