React Server Component에서 Data Fetching을 어느 단계에서 해야 할 지 고민입니다

[maxswjeon]

React 18에서 React Server Component가 등장하면서 Async Component를 통하여 직접 데이터를 가져올 수 있게 되었는데요, 이로 인해서 Data Fetching은 어디서 이루어져야 하는가에 대한 고민이 생겼습니다.

1. Data Fetching은 Page 단에서 이루어져야 한다

Page 단에서 Data를 가져오는 이 접근은 Next.js의 역사적 구조와도 어느 정도 일관성이 있다고 생각합니다. Next.js에서는 Server Side Rendering을 지원하기 위해서 Pages Router를 만들어 냈고, 그 과정에서 getServerSideProps와 같은 Page 단계의 컴포넌트에서만 Data Fetching을 할 수 밖에 없었다고 생각합니다.

장점

해당 방법에 대한 장점은 이후 (2)번 선택지인 Component 단에서 Data Fetching을 수행할 때 발생하는 단점이 나타나지 않는다는 것이 장점이라고 생각합니다.

단점

새로운 데이터가 내부 컴포턴트에서 필요한 경우 해당 페이지의 getServerSideProps의 데이터를 수정해 주어야 한다는 단점이 있습니다. 이로 인해서 캡슐화가 일어나기 어려운 것 같아요. 가장 최선의 방법은 Component를 만들 때 getData 함수를 병렬적으로 정의해 주면 되기도 하겠지만, 이 경우 방법 (2)의 단점 (1)의 문제를 다시 불러 일으킵니다.

2. Data Fetching은 Component에서 이루어져야 한다.

장점

Component를 React Server Component로 작성하면 (1)에서 작성하여야 하였던 getData 함수와 같은 fetcher를 별도로 작성하지 않아도 되며, 사용할 때 데이터 흐름에 대하여 고민하지 않아도 됩니다.

단점

1. 동일한 서버 쿼리가 발생하기 쉽고, N + 1 문제가 발생하기 쉽습니다.
   아래와 같은 Component를 생각해 볼 수 있을 것 같습니다.

   type UserCardProps = {
       userId: string;
   }
   
   async function UserCard({ userId }: UserCardProps) {
       const user = await prisma.users.findUnique({
           where: { id: userId },
       });
       if (!user) {
           return <NoUserCard />;
       }
       
       return (
           <Card>
               <CardHeader>
                   <CardTitle>{user.name}</CardTitle>
                   <CardDescription>{user.description}</CardDescription>
               </CardHeader>
           </Card>
      );
   }
   
   type UserRowProps = {
       userId: string;
   }
   
   async function UserRow({ userId }: UserRowProps ) {
       const user = await prisma.users.findUnique({
           where: { id: userId },
       });
       if (!user) {
           return <NoUserCard />;
       }
       
       return (
           <TableRow>
               <TableCell>{user.name}</TableCell>
               <TabelCell>{user.description}</TableCell>
           </TableRow>
      );
   }
   
   type UserPageProps = {
       searchParams: Record<string, string | string[]>;
   }
   
   export async function UserPage({ searchParams }: UserPageProps) {
       const page = (() => {
           if (!("page" in searchParams)) {
               return 1;
           }
           if (Array.isArray(searchParams.page)) {
               return 1;
           }
           const page = Number(searchParams.page);
           return Number.isNaN(page) ? 1 : page;
       })();
   
       const users = await prisma.users.findMany({
           where: { deletedAt: null },
           select: { id: true },
           skip: (page - 1) * 10,
           take: 10,
       });
   
       return (
           <div>
               <div>
                   <h2>UserTable</h2>
                   <Table>
                       <TableHeader>
                           <TableRow>
                               <TableHead>이름</TableHead>
                               <TableHead>설명</TableHead>
                           </TableRow>
                       </TableHeader>
                       <TableBody>
                           {users.map((user) => <UserRow key={user.id} userId={user.id} />}
                       </TableBody>
                   </Table>
               </div>
               <OtherComponentThatUsesUserCards/>
           </div>
       );
   }

2. 만약 Component에 cookies() 또는 headers() 와 같은 함수가 있다면 해당 Route는 Static Generation이 불가능하게 됩니다.

다른 개발자분들의 의견이 궁금합니다.

[henrysha]

getServerSideProps는 pages 디렉토리에서만 존재하기때문에, Server Component를 쓰기위한 app 디렉토리에서는 사용할 수 없을텐데요,

app 디렉토리에서는 각 서버컴포넌트에서 data fetching 을 하는게 app directory 의 설계의도인 것으로 알고있고, Next.js에서 동일한 요청을 여러 컴포넌트가 수행할 경우, deduplication을 해주는 것으로 알고 있습니다. API 요청 캐싱도 제공하구요.

[maxswjeon]

Next.js의 경우 fetch 함수를 자체적으로 패치해서 deduplication을 해주게 되는데요, 이게 prisma와 같은 DB Connection에서는 적용되지 않는 것으로 알고 있습니다. 최근에 React 19의 cache 함수나 Next.js 자체 unstable_cache같은 게 있긴 했는데요, 생각보다 사용하기 어렵다는 느낌을 받긴 했습니다.

Server Actions를 이용하여 Data Fetching은 지양되고 있는 의견이 주류라, 이런 부분도 고민이 되긴 하더군요. 의견이 궁금합니다.

[ssi02014]

간단한 의견을 남겨보자면.. 저는 data Fetching과 관련된 작업을 react-query를 많이 사용하는 편인데요.
react-query의 경우에는 Query Key를 통해 프로미스를 추적하고 공유하여 중복 호출 문제를 해결하고 있습니다. (swr도 동일하게 제공)

각 컴포넌트에서 data fetching을 수행 할 때 중복 요청 문제는 react-query, swr같은 라이브러리를 사용하는 방법도 있을 것 같습니다 :)

Question: swr deduplicates requests. See dedupingInterval under options. Does react-query do this?

Answer: React Query does this automatically by tracking and sharing promises via the query key. So if 3 requests to fetch the same query are made close to each other, the first will actually fire, create a promise, and the next two will use the promise created by the first. One request, one promise, three promise resolutions
TanStack/query#608

[maxswjeon]

안녕하세요! 저도 react-query를 되게 좋아하는데요, Server Component에서는 난감한 부분이 있어 도입을 꺼리고 있습니다.

Tanstack Query에서도 신규 프로젝트에서는 일단 다른 옵션을 고려해보라는 이야기가 있습니다.

It's hard to give general advice on when it makes sense to pair React Query with Server Components and not. If you are just starting out with a new Server Components app, we suggest you start out with any tools for data fetching your framework provides you with and avoid bringing in React Query until you actually need it. This might be never, and that's fine, use the right tool for the job!

If you do use it, a good rule of thumb is to avoid queryClient.fetchQuery unless you need to catch errors. If you do use it, don't render its result on the server or pass the result to another component, even a Client Component one.

Client Component에서는 react-query를 저도 잘 쓰는데, Server Component에서는 어떻게 사용중이신지 궁금합니다!

[ssi02014]

@maxswjeon 해당 페이지를 읽어봤습니다! Sever Component에서 react-query에 대한 이해도가 높은 편은 아니였는데요. 쿼리 재검증 측면에서 아직 제한적인 부분이 있다는 것을 알았습니다. (현재 react-query에서 공식적으로 제공하는 가이드로하면 큰 문제 없을거라 생각했습니다 🥹)

We are now rendering data from the getPosts query both in a Server Component and in a Client Component. This will be fine for the initial page render, but what happens when the query revalidates on the client for some reason when staleTime has been passed?

React Query has no idea of how to revalidate the Server Component, so if it refetches the data on the client, causing React to rerender the list of posts, the Nr of posts: {posts.length} will end up out of sync.

This is fine if you set staleTime: Infinity, so that React Query never revalidates, but this is probably not what you want if you are using React Query in the first place.

따라서, 현재 react-query가 아직 Sever Component에서는 제한적인 부분이 있고, 실제로 타 프레임워크에서 제공하는 기능을 우선적으로 사용하는걸 권장하고 있군요. 단순하게 컴포넌트 단에서 API Fetching 중복 호출에 대해서만 생각하고, 질문의 최초 의도가 서버 컴포넌트가 전제임을 깊게 생각하지 않고 답변을 남겼네요 😅 새로운 정보를 얻어갑니다 감사합니다

[oungo]

저는 data fetching이 컴포넌트에서 이루어져야한다고 생각합니다.

기존에는 ssr을 위해 페이지에서만 data fetching이 가능했습니다. 그러다보니 html을 다운받고, js를 다운로드받아 전체 페이지에 대한 hydration이 이루어지게됩니다. 결국 페이지를 그리기 위해서는 getServerSideProps에 있는 모든 data fetching이 이루어야하고, 페이지 내의 모든 컴포넌트를 다운받고, 하이드레이션 과정이 선행되어야 하는거죠.

하지만 서버 컴포넌트를 사용할 경우 컴포넌트에서 data fetching이 가능합니다. 이를 통해 페이지에 존재 하는 컴포넌트들을 여러개의 chunk들로 쪼갤 수 있고, streaming을 통해 서버에서 클라이언트로 전달할 수 있습니다. 우선순위가 높은 영역만 먼저 hydration이 가능하고, 중요도가 떨어지는 부분은 별도의 hydration을 통해 그릴 수 있게됩니다. TTFB나 FCP 등 성능 측면에서도 더 유리한 방향이기도 하구요.

결국 data fetching을 컴포넌트에서 하는게 가능해지면서 전체 페이지를 hydration해야만 했던 기존과는 다르게 selective hydration이 가능해진 상황에서 이를 활용하지 않을 이유는 없다고 생각합니다. 물론 경우에 따라서는 페이지 단위에서 호출하는게 더 나을 수도 있겠지만요.

말씀하신 단점의 경우는 fetch를 사용한다면 request memoization을 통해 중복 호출을 막아줄 수 있는걸로 알고 있는데요. prisma 같은걸 사용한다면 cache function의 사용을 고려해볼 수 밖에 없을것같아요. cookie()나 headers()의 경우 request에 따라 달라질 수 있는 정보라서 ssg가 불가능한게 어찌보면 당연한 동작이라는 생각이 듭니다.

[croishz]

SEO 컨텐츠에 대한 관리 포인트를 어떻게 다루느냐.
페칭 상태에 따른 뷰 케이스 제어를 어디서 처리하는 것이 효율적인가.
의존적인 렌더링 또는 요청이 아닐 때애도 waterfall이 발생하는 것을 허용할 것인가.

이 문제에 대한 화두는 여러가지가 있다고 보이네요.

app router에서 page 컨벤션을 활용해서 fetching 하는 효과는 관리 포인트를 프레임워크 동작 방식에 맞춘다는 것에 있습니다.
parallel routing을 지원하여 아일랜드 레이아웃 구성이 가능하기에 page 컨벤션은 사용하기에 따라 route가 아니고 domain section 이나 페칭 컴포넌트로 간주할 수 있을텐데, 이는 본문의 컴포넌트 페칭과 다르지 않으리라 보입니다.

데이터의 목적? 또는 렌더링의 목적. 관리 포인트. 화면 제어... 이런 화제에 대한 스탠스가 코드의 형태도 결정하지 않을까 싶네요.