Photo by Randy Tarampi
TkDodo의 You Might Not Need React Query를 번역한 글입니다.
React Server Component가 React Query를 없애버릴까요? 제가 지난 몇 달간 가장 많이 받은 질문일 겁니다. 사실 적절한 답이 없습니다. 이 업계의 개발자 대부분이 그렇듯 저도 그냥 그때그때 만들어 내고 있다는 걸 기억해 주세요. 제가 모든 것에 대한 거창한 계획이 있을 거라 기대하신다면 실망시켜 드리겠습니다. 결말이 어떻게 될지 저도 여러분만큼이나 궁금합니다. 😅
(데이터 fetching 분야 라이브러리의 메인테이너로서) 서버 컴포넌트와 서스펜스에 대해 솔직히 두려움이 제일 큽니다.
"이게 react-query에 어떤 영향을 줄까요"는 좋은 질문입니다. 저는 답을 알아야 할 거 같은데 모르겠네요. 지금 엄청난 가면 증후군을 느낍니다.
- 2022. 10. 26
TkDodo의 트윗
그래도 이 주제를 좀 더 자세히 살펴볼 시간이 있었고 이 주제에 대해 저보다 더 많이 알고 있는 분들과도 토론해봤습니다. 이제 이 주제에 대한 제 의견을 말씀드릴 수 있을 정도의 자신감이 생겼습니다. 하지만 어디까지나 제 생각일 뿐이니까 신중하게 받아들이시기를 바랍니다.
제 생각
우리가 사용하는 모든 도구는 우리가 가진 문제를 해결하는 데 도움이 되어야 합니다. 예전부터 React는 애플리케이션에서 데이터를 fetch 하는 방식에 대해 딱히 강요하지 않았습니다. 말 그대로 '여기 useEffect 있으니까 원하는 거 해봐'라는 식으로 신경 쓰지 않았죠.
바로 이 시기에 React Query나 swr같은 라이브러리가 탄생했습니다. 이 라이브러리들은 꽤 큰 공백을 메웠고, 뛰어난 DX와 사용자를 위한 개선점으로 인해 빠르게 채택되었습니다. "뷰" 라이브러리가 라우팅과 관련된 어떠한 기능도 제공하지 않을 때 그 필요성을 해결한 React Router도 비슷한 범주에 속합니다.
서버 사이드 렌더링이 유행했을 때 저희는 첫 페이지 로딩을 빠르게 하기 위한 서버에서의 html 사전 렌더링에 주로 집중했습니다. 첫 페이지 로딩 후, 앱은 클라이언트 측 페이지 내비게이션 등을 통해 완전한 SPA처럼 동작합니다. 이런 상황에서 React Query도 중요한 역할을 합니다. 첫 데이터 fetch를 서버로 옮기고 클라이언트에서는 그 fetch의 결과를 하이드레이트 할 수 있게 하죠. 이건 서버에서 최대한 빠르게 캐시를 채울 수 있게 해주는 좋은 방법입니다.
그래서 뭐가 변했나요?
시대가 진화하고 있고, 상황은 더 좋아지고 있습니다. 앞뒤로 왔다 갔다 하는 것처럼 보이지만 사실은 앞으로 나아가고 있습니다.
저는 @Mappletons가 더 잘할 수 있다고 확신하는데, "개발자들은 왔다 갔다 무한 반복한다"는 댓글을 볼 때마다 제 머릿속에선 이런 게 보입니다.
- 2023. 5. 12
swyx의 트윗
React는 여전히 컴포넌트를 렌더링하는 라이브러리일 뿐이지만, 서버 컴포넌트를 사용하면 서버에서의 사전 렌더링이 가능한 새로운 애플리케이션 아키텍처를 제공합니다. 빌드타임이나 런타임에 데이터에 접근할 수 있게 함으로써 클라이언트에서 쿼리해야 하는 API를 만들지 않아도 되죠.
export default async function Page() {
const data = await fetch(
`https://api.github.com/repos/tanstack/react-query`
)
return (
<div>
<h1>{data.name}</h1>
<p>{data.description}</p>
</div>
)
}React 컴포넌트 안에서 async/await를 사용하는 게 그냥 된다는 게 여전히 놀랍고, 프레임워크가 문제를 포착해서 최고 수준의 해결책을 제공하는 걸 보면 흥미진진합니다. 이건 이 아키텍처를 채택하는 애플리케이션의 상황을 극적으로 변화시킵니다. React Query는 무엇보다도 클라이언트에서 비동기 상태를 관리하기 위한 라이브러리입니다. 데이터 fetching을 서버에서만 한다면 React Query가 필요할 이유가 있을까요?
필요 없을 수도 있어요
아마도 필요없을 거라는 게 제 대답입니다. Next.js나 Remix처럼 데이터의 fetching과 mutation이 잘 구상된 성숙한 프레임워크로 새 애플리케이션을 시작한다면 React Query는 필요 없을 겁니다.
그리고 정말 괜찮습니다. 제가 React Query의 메인테이너라고 해서 모든 상황에 React Query를 사용하라고 할 수는 없습니다. React Query를 사용하기로 했다면, 그 이유는 "문제 해결에 도움됨"이어야 합니다.
통합
서버 컴포넌트라는 새로운 세계엔 React Query를 통합시킬 만한 지점이 아직 많이 있습니다. 우선, 대부분의 프로젝트는 백지상태에서 시작하지 않습니다. 수년에 걸쳐 구축된 수많은 애플리케이션이 존재하며, 점진적으로 app 디렉토리를 적용할 수는 있지만 서버 컴포넌트를 활용하려면 어느 정도의 재설계가 필요합니다.
이런 과도기에 React Query는 app 디렉토리 및 서버 컴포넌트와 아주 잘 통합됩니다. 일부 컴포넌트를 옮겨서 서버에서만 fetch 하도록 하거나, 서버 컴포넌트로 캐시를 prefetch 한 뒤에 useQuery를 사용하는 클라이언트 컴포넌트에 전달할 수도 있습니다. 모 아니면 도일 필요는 없죠. 공식 문서에 이미 이런 통합에 대한 좋은 가이드가 있으며, 저는 거기에 덧붙여 주의 사항에 대한 블로그 글을 작성할 겁니다.
하이브리드 접근법
하이브리드 접근법은 서버 컴포넌트가 (아직) 잘 지원하지 않는 용례를 마주칠 때 특히 유용할 겁니다.
예를 들어, 무한 스크롤 목록을 렌더링할 때 첫 페이지는 서버에서 prefetch하고, 사용자가 끝까지 스크롤 했을 때는 클라이언트에서 더 많은 페이지를 가져오는 경우가 있습니다. 아니면 네트워크 연결 없이도 앱이 작동해야 한다는 요구 사항이 있을 수도 있죠. 또, 사용자의 명시적인 상호작용 없이도 항상 새로운 데이터를 볼 수 있는 사용자 경험을 원하는 경우도 있습니다(일정 간격으로 fetch 하는 거나 React Query에서 제공하는 모든 자동 refetch를 생각해 보세요).
React Query에는 이 모든 상황에 대해 잘 구상되어 있으므로 서버 컴포넌트와 결합하는 것이 분명 타당한 경우가 존재합니다. 하지만 React Query의 주 용도가 데이터를 fetch 해서 사용자에게 보여주는 것이었다면 서버 컴포넌트로도 충분히 대신할 수 있을 겁니다. 그리고 mutation(서버 액션) 패턴이 확실히 자리를 잡으면, 데이터 업데이트에도 필요없어질 수 있습니다.
"킬러"는 아닙니다
다양한 이유로 인해 모두가 서버 컴포넌트를 채택하진 않을 거라는 것도 타당하다고 생각합니다. 백엔드가 nodeJs로 작성되지 않았을 수도 있으며, 프런트엔드가 전용 서버 없는 SPA여도 괜찮습니다. React Native로 모바일 앱을 만들고 있을 수도 있죠. Tanstack Query 사용자라면 React를 아예 사용하지 않을 수도 있습니다.
게다가 데이터 fetch 이외의 작업에 React Query를 사용할 수 있습니다. 이 트윗에 달린 답글을 보고 영감을 받아보세요.
데이터 fetching이 아닌 다른 용도로 TanStack Query를 사용하고 계신다면 어떤 것들이 있나요? 다른 용례는 어떤 게 있는지 궁금합니다 😄.
- 2023. 1. 20
TkDodo의 트윗
이 모든 용례는 클라이언트에서 비동기 상태 관리자로 Tanstack Query를 선택하기 완벽하게 좋은 예시입니다. 하지만 이걸 기본으로 지원하는 내장 기능이 있는 프레임워크를 선택하기로 했다면 그 기능을 사용하세요! 제 말은, Remix를 사용하면서 loader에서 데이터를 fetch 하지 않을 이유가 있을까요? 🤷♂️
저는 Tanstack Query를 RSC 외부에서, 심지어는 결합해서도 사용하는 경우가 여전히 많을 거라고 예상합니다. 지금 다들 RSC에 대해 이야기하지만 괜찮습니다. 모두가 사용해 보고 싶어 하는 새롭고 반짝이는 기술이니까요.
그래도 RSC는 아직 초기 단계인 최첨단 기술입니다. 사용하려면 프레임워크, 라우터, 번들러와 긴밀하게 통합해야 하죠. 추가적인 서버 부하를 처리할 수 있는 인프라가 있어야 한다는 뜻이기도 합니다. 저 스스로 계속 반복하는 말이지만,
공짜 점심은 없어요. 모든 것은 트레이드-오프입니다.
그래서 저는 모든 것을 즉시 서버 컴포넌트로 이전시켜야 한다는 의무감을 느끼진 않습니다. Next.js 사용자로서 앱을 app 디렉토리로 옮기게 되어 기쁩니다. 중첩 route가 주는 장점이 주된 이유이죠. 그리고 좀 더 정적인 데이터 fetch(예를 들어, staleTime: Infinity를 사용하는 곳)은 확실히 서버 컴포넌트로 옮길 겁니다.
그래도 React Query의 사망 보도는 크게 과장된 겁니다.
