[번역] React Query가 필요 없을 수도 있습니다.

이춘구·2023년 5월 21일
7

translation

목록 보기
7/11

Photo by Randy Tarampi

TkDodoYou Might Not Need React Query를 번역한 글입니다.


React Server Component가 React Query를 없애버릴까요? 제가 지난 몇 달간 가장 많이 받은 질문일 겁니다. 실은, 괜찮은 답변이 없습니다. 이 업계의 개발자 대부분이 그렇듯 저도 그냥 그때그때 만들어 내고 있다는 걸 기억해 주세요. 제가 모든 것에 대한 거창한 계획이 있을 거라 기대하신다면 실망하게 해 드리죠. 결말이 어떻게 될지 저도 여러분만큼이나 궁금합니다. 😅

(데이터 fetching 분야 라이브러리의 메인테이너로서) 서버 컴포넌트와 서스펜스에 대해 솔직히 두려움이 제일 큽니다.
"이게 react-query에 무슨 영향을 끼칠까요"는 좋은 질문입니다. 저라면 답을 알고 있어야 할 거 같은데 모르겠네요. 지금 엄청난 가면 증후군을 느낍니다.
- 2022. 10. 26
TkDodo의 트윗

그래도 이 주제를 좀 더 자세히 살펴볼 시간이 있었고 저보다 이 주제에 대해 더 많이 알고 있는 분들과도 논의했습니다. 이제 이 주제에 대한 제 의견을 말씀드릴 수 있을 만큼 자신감이 생겼습니다. 하지만 어디까지나 제 생각일 뿐이니까 신중하게 받아들이시기를 바랍니다.

제 생각

우리가 사용하는 모든 도구는 우리가 가진 문제를 해결하는 데 도움이 되어야 합니다. 예전부터 React는 애플리케이션에서 데이터를 fetch 하는 방식에 대해 딱히 강요하지 않았습니다. 말 그대로 '여기 useEffect 있으니까 원하는 거 해봐'라는 식으로 신경 쓰지 않았죠.

바로 이 시기에 React Queryswr같은 라이브러리가 탄생했습니다. 이 라이브러리들은 꽤 큰 공백을 메웠고, 뛰어난 DX와 사용자를 위한 개선으로 인해 빠르게 채택되었습니다. React Router도 비슷하게, "뷰" 라이브러리가 당장 해줄 수 있는 게 없을 때 라우팅의 필요성을 해결해 줬죠.

서버 사이드 렌더링이 유행했을 때 저희는 초기 페이지 로딩을 빠르게 하려고 서버에서 html을 미리 렌더링하는 데 주로 집중했습니다. 앱은 초기 페이지 로딩 후에 클라이언트 사이드 페이지 내비게이션 등 완전히 SPA처럼 동작합니다. 이런 상황에서 React Query도 중요한 역할을 합니다. 초기 데이터 fetching을 서버로 옮긴 다음 클라이언트에서 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.jsRemix처럼 데이터 fetching과 mutation에 대해 좋은 이야기가 있는 발달한 프레임워크를 사용한다면 React Query는 필요 없을 겁니다.

그리고 정말 괜찮습니다. 제가 React Query의 메인테이너라고 해서 모든 상황에 React Query를 사용하라고 할 수는 없습니다. React Query를 사용하기로 했다면 문제 해결에 도움이 되기 때문이어야 합니다.

통합

서버 컴포넌트라는 새로운 세계엔 React Query를 통합시킬 만한 지점이 아직 많이 있습니다. 우선, 대부분 프로젝트는 백지상태에서 시작하지 않습니다. 수년에 걸쳐 구축된 수많은 애플리케이션이 존재하고 점진적으로 app 디렉토리를 채택할 수는 있지만, 서버 컴포넌트를 활용하려면 어느 정도의 재설계가 필요합니다.

이런 과도기에 React Query는 app 디렉토리, 서버 컴포넌트와 아주 잘 통합됩니다. 일부 컴포넌트를 옮겨서 서버에서만 fetch 하도록 하거나, 서버 컴포넌트로 캐시를 prefetch 한 뒤에 useQuery를 사용하는 클라이언트 컴포넌트에 전달할 수도 있습니다. 모 아니면 도일 필요는 없습니다. 공식 문서에 이미 이런 통합에 대한 좋은 가이드가 있고, 저는 거기에 덧붙여 주의해야 할 것들에 대한 블로그 글을 작성할 겁니다.

하이브리드 접근법

이 하이브리드 접근법은 서버 컴포넌트에서 (아직) 잘 지원되지 않는 사용 사례를 마주칠 때 특히 유용할 수 있습니다.

예를 들어 무한 스크롤 되는 목록을 렌더링할 때 첫 페이지는 서버에서 prefetch하고, 사용자가 끝까지 스크롤 했을 때는 클라이언트에서 더 많은 페이지를 가져오고 싶을 수 있습니다. 아니면 네트워크 연결 없이도 앱이 작동해야 한다는 요구 사항이 있을 수도 있죠. 또, 사용자의 명시적인 상호작용 없이도 항상 새로운 데이터를 볼 수 있는 사용자 경험을 원할 수도 있습니다(일정 간격으로 fetching 하는 거나 React Query에서 제공하는 모든 자동 refetch를 생각해 보세요).

React Query는 이 모든 상황에 대한 훌륭한 설명이 있어서 서버 컴포넌트와 결합하는 게 타당한 경우가 분명히 있습니다. 하지만 React Query를 주로 데이터를 fetch 해서 사용자에게 보여주는 데 사용했다면 서버 컴포넌트로도 충분히 커버할 수 있을 겁니다. 그리고 mutation(서버 액션)이 확실히 자리를 잡으면 데이터를 업데이트할 때도 필요 없을 수 있습니다.

"킬러"는 아닙니다

여러 가지 이유로 모든 사람이 서버 컴포넌트를 채택하진 않을 거라는 것도 말이 된다고 생각합니다. 백엔드가 nodeJs로 작성되지 않았을 수도 있죠. 프론트엔드 전용 서버가 없는 SPA여도 괜찮습니다. React Native로 모바일 앱을 만들고 있을 수도 있죠. Tanstack Query 사용자라면 React를 아예 사용하지 않을 수도 있습니다.

게다가 데이터 fetching 이외의 작업에 React Query를 사용할 수 있습니다. 이 트윗에 달린 답글을 보고 영감을 얻어보세요.

데이터 fetching이 아닌 다른 용도로 TanStack Query를 사용하고 계신다면 어떤 것들이 있나요? 다른 사용 사례는 어떤 게 있는지 궁금합니다 😄.
- 2023. 1. 20
TkDodo의 트윗

이 모든 사용 사례는 클라이언트에서 비동기 상태 관리자로 Query를 선택하기에 완벽하게 좋은 사례들입니다. 하지만 이걸 기본으로 지원하는 내장 기능이 있는 프레임워크를 선택하기로 했다면 그 기능을 사용하세요! 제 말은, Remix를 사용하면서 loader에서 데이터를 fetch 하지 않을 이유가 있을까요? 🤷‍♂️

저는 Tanstack Query를 React 서버 컴포넌트 외부에서, 심지어는 결합해서도 사용하는 경우가 여전히 많을 거라고 예상합니다. 지금 다들 RSC에 관해서만 이야기하지만 괜찮아요. 모두가 사용해 보고 싶어 하는 새롭고 반짝이는 기술이니까요.

그래도 RSC는 아직 초기 단계인 최첨단 기술입니다. 사용하려면 프레임워크, 라우터, 번들러와 긴밀하게 통합해야 하죠. 추가적인 서버 부하를 처리할 수 있는 인프라가 있어야 한다는 뜻이기도 합니다. 저 스스로 계속 반복하는 말이지만,

공짜 점심은 없어요. 모든 것은 트레이드-오프입니다.

그래서 저는 모든 것을 즉시 서버 컴포넌트로 이전시켜야 한다는 의무감을 느끼진 않습니다. Next.js 사용자로서 앱을 app 디렉토리로 옮기게 되어 기쁩니다. 중첩 route의 장점이 주된 이유이죠. 그리고 좀 더 정적인 데이터 fetching(예를 들어 staleTime: Infinity를 사용하는 곳)은 분명히 서버 컴포넌트로 옮길 겁니다.

그래도 React Query 사망신고는 엄청나게 과장된 겁니다.

profile
프런트엔드 개발자

0개의 댓글