React Server Component - Githubissues

Q. React Server Component에서의 stream이 무엇인지랑 React Server Component를 사용하면 client에 전달되는 번들 크기가 줄어드는 이유도 알려줘.

A. React Server Component (RSC)에서의 "stream"은 컴포넌트의 일부가 렌더링되는 동안 이벤트나 데이터를 통해 서버와 클라이언트 간에 실시간으로 통신하는 방식을 의미합니다. 일반적으로, 서버는 컴포넌트의 각 부분을 렌더링하고 클라이언트에게 전달하기 전에 완전한 HTML 문서를 생성합니다. 그러나 RSC에서는 컴포넌트가 조각조각씩 스트리밍되면서 서버와 클라이언트 사이에서 데이터를 주고받을 수 있습니다. 이는 사용자 경험을 향상시킬 수 있는 다이나믹한 기능을 구현하는 데 유용합니다.

React Server Component를 사용하면 클라이언트에 전달되는 번들 크기가 줄어듭니다. 이는 RSC의 동작 원리에 기인합니다. RSC는 컴포넌트를 렌더링하기 위해 서버에서 필요한 최소한의 JavaScript 코드만을 전달합니다. 서버는 클라이언트에게 컴포넌트의 초기 상태와 상호작용을 위해 필요한 데이터만 전송합니다. 클라이언트는 이후에 필요한 추가적인 컴포넌트 코드를 스트리밍 방식으로 요청하고, 서버는 필요한 컴포넌트 코드를 동적으로 전송합니다. 이로써, 초기 로딩 시에 필요한 번들 크기를 줄이고 필요한 코드를 지연 로딩할 수 있습니다.

React Server Component의 이점:

번들 크기 감소: 초기 로딩 시에 필요한 JavaScript 번들 크기를 줄여 성능을 향상시킵니다.
동적 로딩: 필요한 컴포넌트 코드를 필요한 시점에 동적으로 로딩하여 효율적인 자원 사용을 가능하게 합니다.
서버-클라이언트 상호작용: 컴포넌트 렌더링 도중에 실시간으로 서버와 클라이언트 간에 데이터를 주고받을 수 있습니다.

React Server Component의 단점:

실험적인 기능: React Server Component는 아직 실험적인 기능으로 정식 릴리즈되지 않았으며, 안정성과 성능 측면에서 아직 일부 제한이 있을 수 있습니다.
학습 곡선: 기존의 React 개발자들이 새로운 컨셉과 패턴을 익혀야 할 수 있습니다.

Next.js를 사용하면 SSR과 RSC를 동시에 사용할 수 있습니다. Next.js는 React 기반의 프레임워크로서, SSR을 지원하면서도 React Server Component와 같은 최신 기술을 활용할 수 있는 환경을 제공합니다. Next.js에서는 페이지 단위로 SSR을 수행하고, 필요한 경우 RSC를 사용하여 페이지 내에서 동적인 컴포넌트 렌더링을 수행할 수 있습니다.

Client와 Server 사이의 통신 흐름은 다음과 같습니다:

클라이언트가 페이지 요청을 서버로 보냅니다.
Next.js 서버는 해당 페이지에 대한 SSR을 수행하여 초기 HTML과 필요한 JavaScript 번들을 생성합니다.
클라이언트는 초기 HTML과 JavaScript 번들을 받고 페이지를 렌더링합니다.
필요한 RSC 컴포넌트가 있을 경우, 클라이언트는 서버에게 해당 컴포넌트의 추가적인 코드를 스트리밍 요청합니다.
서버는 필요한 컴포넌트 코드를 스트리밍 방식으로 클라이언트에게 전송하고, 클라이언트는 해당 컴포넌트를 렌더링합니다.
클라이언트와 서버는 필요에 따라 데이터나 이벤트를 주고받으며 상호작용합니다.

이렇게 함으로써, 초기 로딩 속도를 개선하고 동적인 컴포넌트 렌더링을 가능하게 하면서도 SSR의 이점을 유지할 수 있습니다.

Q. React Server Component에서 컴포넌트가 serialize된다는 표현을 많이 사용하는데 그게 무슨 뜻이야?

A. "컴포넌트가 serialize된다"는 표현은 React Server Component에서 컴포넌트의 상태와 로직이 서버에서 클라이언트로 전송되고, 클라이언트에서 재사용될 수 있도록 변환되는 과정을 의미합니다.

React 컴포넌트는 일반적으로 클라이언트 측에서 JavaScript로 실행되기 위해 구성됩니다. 그러나 React Server Component는 서버 측에서 실행되는 동안 컴포넌트의 상태와 로직을 클라이언트로 전송할 수 있어야 합니다. 이를 위해 컴포넌트는 일종의 직렬화(serialization) 과정을 거쳐야 합니다.

컴포넌트의 직렬화는 컴포넌트 인스턴스를 일련의 데이터 형식으로 변환하는 과정입니다. 이 데이터 형식은 클라이언트로 전송된 후, 클라이언트에서 다시 역직렬화(deserialization)되어 클라이언트 측에서 실행 가능한 형태로 재구성됩니다. 이렇게 함으로써 서버에서 생성된 컴포넌트의 상태와 로직을 클라이언트에서 동일하게 재사용할 수 있게 됩니다.

React Server Component는 서버에서 클라이언트로 컴포넌트를 전송하기 위해 JSON 형식을 주로 사용합니다. 컴포넌트의 상태, 프로퍼티, 메서드 등은 JSON으로 직렬화되어 클라이언트로 전송되고, 클라이언트에서는 해당 JSON 데이터를 해석하여 컴포넌트를 재구성합니다.

이렇게 컴포넌트가 serialize되고 deserialize되는 과정을 통해 React Server Component는 서버와 클라이언트 사이에서 컴포넌트의 상태와 로직을 공유하고 재사용할 수 있게 됩니다.

Q. Server Side Rendering과 React Server Component를 비교해봐. 목적, 효과, 원리, 장점, 단점 등을 포함해서.

A. 서버 측 렌더링(Server Side Rendering, SSR)과 React Server Component(RSC)는 모두 React 애플리케이션의 서버 측 렌더링을 위한 기술이지만, 목적, 효과, 원리, 장점, 단점 등에서 차이가 있습니다.

서버 측 렌더링 (SSR):
- 목적: 클라이언트 측에서 JavaScript를 실행하지 않고 서버에서 초기 렌더링된 HTML을 전송하여 검색 엔진 최적화(SEO)와 초기 로딩 속도 개선을 목표로 합니다.
- 효과: 초기 렌더링 시 클라이언트에게 완전한 HTML을 제공하여 페이지의 콘텐츠가 빠르게 표시되고, 검색 엔진에서 쉽게 색인할 수 있습니다.
- 원리: 서버에서 React 컴포넌트를 실행하여 초기 HTML을 생성하고, 클라이언트에게 전송합니다. 클라이언트는 해당 HTML을 받아와서 상호작용이 필요한 경우 JavaScript를 실행하여 동적으로 업데이트합니다.
- 장점:
- SEO: 검색 엔진 최적화를 위해 초기 렌더링된 HTML을 제공할 수 있습니다.
- 초기 로딩 속도: 서버에서 렌더링된 HTML을 제공하므로 초기 로딩 속도가 개선될 수 있습니다.
- 단점:
- 서버 부하: 서버에서 렌더링을 수행하므로 서버에 부하가 걸릴 수 있습니다.
- 클라이언트에서의 자바스크립트 실행: 클라이언트에서는 자바스크립트를 실행하여 상호작용을 처리해야 하므로, 초기 로딩 속도를 향상시키기 위해 추가적인 작업이 필요할 수 있습니다.
React Server Component (RSC):
- 목적: 컴포넌트의 상태와 로직을 서버와 클라이언트 사이에서 공유하며, 동적으로 컴포넌트를 렌더링하고 상호작용을 처리하는 것을 목표로 합니다.
- 효과: 컴포넌트의 상태와 로직을 서버와 클라이언트 간에 공유하여 일관된 동작을 유지하고, 필요한 컴포넌트를 동적으로 로딩하고 업데이트할 수 있습니다.
- 원리: RSC는 서버에서 클라이언트로 직렬화된 형태로 컴포넌트를 전송하고, 클라이언트는 해당 컴포넌트를 역직렬화하여 렌더링하고 상호작용을 처리합니다.
- 장점:
- 동적 렌더링: 필요한 컴포넌트를 동적으로 로딩하고 업데이트할 수 있습니다.
- 서버-클라이언트 상호작용: 서버와 클라이언트 간에 컴포넌트의 상태와 로직을 공유하여 실시간 상호작용을 처리할 수 있습니다.
- 번들 크기 감소: 필요한 컴포넌트 코드만 전달하므로 번들 크기가 줄어들어 초기 로딩 속도를 향상시킬 수 있습니다.
- 단점:
- 실험적인 기능: 아직 실험적인 기능으로 정식 릴리즈되지 않았으며, 일부 제한과 안정성 문제가 있을 수 있습니다.
- 학습 곡선: 새로운 개념과 패턴을 익혀야 할 수 있으며, 기존 React 개발자들에게는 추가적인 학습이 필요합니다.

서버 측 렌더링과 React Server Component는 각각의 목적과 특징에 따라 선택되어야 합니다. SSR은 초기 로딩 속도 개선과 SEO를 중요시하는 경우에 유용하며, RSC는 동적 렌더링과 서버-클라이언트 상호작용을 필요로 하는 경우에 적합합니다.

Q. RSC는 컴포넌트를 렌더링하기 위해 서버에서 필요한 최소한의 JavaScript 코드만을 전달합니다. 서버는 클라이언트에게 컴포넌트의 초기 상태와 상호작용을 위해 필요한 데이터만 전송합니다. 너가 이렇게 말했잖아. 그러면 결국에 서버에서 클라이언트 전달하는 데이터 크기는 같지만 "초기"에 전달하는 크기가 달라진다는 뜻이야?

A. RSC를 사용할 때, 초기에 서버에서 클라이언트로 전송되는 데이터의 크기는 기존의 전체 컴포넌트 코드를 포함하는 번들 크기와 비교하여 상대적으로 작아질 수 있습니다. 이는 RSC가 필요한 컴포넌트의 최소한의 JavaScript 코드만을 전달하기 때문입니다.

기존의 SSR에서는 클라이언트로 전송되는 HTML과 JavaScript 번들에는 페이지에서 사용되는 모든 컴포넌트의 코드가 포함되어 있습니다. 따라서 초기에 전송되는 데이터의 크기는 상대적으로 큽니다.

하지만 RSC에서는 컴포넌트의 최소한의 JavaScript 코드만을 전달하고, 컴포넌트의 초기 상태와 상호작용을 위해 필요한 데이터만 전송합니다. 이렇게 하면 초기에 전달되는 데이터의 크기가 기존의 번들 크기보다 작아질 수 있습니다.

예를 들어, SSR의 경우 모든 컴포넌트 코드를 포함하는 번들이 100KB라면, 초기에 전송되는 데이터의 크기는 100KB에 가까울 것입니다. 반면 RSC의 경우 필요한 컴포넌트의 최소한의 코드만을 전달하므로, 데이터의 크기는 그보다 훨씬 작을 수 있습니다. 예를 들어, RSC에서는 해당 컴포넌트의 코드가 5KB라면 초기에 전달되는 데이터의 크기는 5KB에 가깝게 될 것입니다.

따라서 RSC를 사용하면 초기 데이터 전송의 크기를 줄일 수 있으며, 이는 초기 로딩 속도를 향상시킬 수 있는 장점으로 작용합니다.

Q. RSC에서 스트리밍 방식으로 요청한다는 게 무슨 뜻이야? 동영상 실시간 스트리밍 할 때 그 의미야?

A. RSC에서 "스트리밍 방식으로 요청한다"는 표현은 동영상 실시간 스트리밍과는 다른 개념입니다. RSC의 스트리밍은 컴포넌트의 렌더링을 단계적으로 처리하고 전송하는 방식을 의미합니다.

RSC는 컴포넌트를 여러 단계로 나누어 서버에서 클라이언트로 전송할 수 있습니다. 이를 통해 초기 요청 시에 필요한 최소한의 데이터를 먼저 전송하고, 이후 추가적인 데이터를 스트리밍 방식으로 전송하여 컴포넌트를 완전히 렌더링할 수 있습니다.

스트리밍 방식으로 RSC를 요청하면, 서버는 초기 데이터와 함께 클라이언트로부터 추가 데이터를 요청하는 "요청 청크(request chunk)"를 받을 수 있습니다. 이후 서버는 해당 요청 청크에 필요한 데이터를 응답으로 보내고, 클라이언트는 이를 받아 컴포넌트를 계속해서 렌더링하고 업데이트합니다. 이 과정을 반복하여 컴포넌트의 완전한 렌더링과 상호작용을 구현할 수 있습니다.

스트리밍 방식을 사용하면 초기 렌더링을 더 빠르게 시작할 수 있고, 필요한 데이터가 도착하는 대로 화면을 업데이트할 수 있습니다. 이는 사용자 경험을 향상시키고 초기 로딩 시간을 줄이는 데 도움이 됩니다.

따라서 RSC의 스트리밍은 동영상 실시간 스트리밍과는 다른 개념으로, 컴포넌트의 렌더링과 데이터 전송을 단계적으로 처리하는 방식을 나타냅니다.

Q. 그럼 code splitting을 통해서 서버 응답을 쪼개 보내는 거하고 다른 게 뭐야?

A. RSC의 스트리밍과 Code Splitting은 서로 다른 개념이며 다른 목적을 가지고 있습니다.

RSC의 스트리밍: RSC의 스트리밍은 컴포넌트의 렌더링을 단계적으로 처리하고 서버에서 클라이언트로 데이터를 전송하는 방식을 의미합니다. 이를 통해 초기 요청 시에 필요한 최소한의 데이터를 먼저 전송하고, 이후 추가적인 데이터를 스트리밍 방식으로 전송하여 컴포넌트를 완전히 렌더링할 수 있습니다. RSC의 스트리밍은 초기 렌더링을 빠르게 시작하고 필요한 데이터가 도착하는 대로 화면을 업데이트하는 데 사용됩니다.

Code Splitting: Code Splitting은 번들된 JavaScript 코드를 여러 개의 작은 청크로 분할하는 기술을 말합니다. 일반적으로 웹 애플리케이션에서 번들된 JavaScript 파일은 초기에 모두 다운로드되어야 합니다. 그러나 Code Splitting을 사용하면 애플리케이션의 다양한 부분을 독립된 청크로 분할하여 필요한 부분만 동적으로 로드할 수 있습니다. 이를 통해 초기 로딩 시에 필요한 부분만 다운로드하여 초기 로딩 속도를 개선할 수 있습니다.

Code Splitting은 번들된 JavaScript 코드를 작은 청크로 분할하는 방식이며, 애플리케이션의 여러 영역을 독립된 파일로 분리하여 필요한 부분만 로드할 수 있도록 합니다. 이는 초기 로딩 속도를 향상시키고 사용자 경험을 개선하는 데 도움이 됩니다.

따라서 RSC의 스트리밍은 컴포넌트의 렌더링과 데이터 전송을 단계적으로 처리하는 방식을 나타내고, Code Splitting은 번들된 JavaScript 코드를 작은 청크로 분할하여 필요한 부분만 로드하는 기술을 말합니다. 두 기술은 서로 다른 목적을 가지고 있으며, 각각 애플리케이션의 성능 개선에 활용됩니다.

Q. RSC는 그러면 한 번의 요청에 대해 HTTP 응답을 끊지 않고 지속적으로 클라이언트 측에 컴포넌트를 보내줘?

A. 네, 맞습니다. RSC는 일반적으로 한 번의 HTTP 요청에 대해 응답을 여러 번 보내줍니다. 서버는 초기 요청에 대한 응답으로 최소한의 데이터를 전송하고, 이후에는 추가적인 데이터를 스트리밍 방식으로 클라이언트에게 전송합니다.

서버는 초기 응답에서 RSC 컴포넌트의 최소한의 JavaScript 코드와 초기 상태를 전송합니다. 이것은 클라이언트에서 컴포넌트를 시작하는 데 필요한 기본적인 구조와 데이터를 가지고 있게 합니다. 그런 다음, 클라이언트는 추가적인 데이터를 요청 청크(request chunk)로 서버에 보냅니다. 서버는 해당 요청 청크에 필요한 데이터를 응답으로 보내고, 클라이언트는 이를 받아 컴포넌트를 업데이트합니다.

이러한 방식으로 서버와 클라이언트 간에 지속적인 통신을 통해 컴포넌트의 완전한 렌더링과 상호작용을 구현할 수 있습니다. 서버는 클라이언트의 요청에 따라 필요한 데이터를 동적으로 생성하고 전송하여 컴포넌트를 계속해서 업데이트할 수 있습니다.

따라서 RSC에서는 한 번의 요청에 대해 HTTP 응답을 끊지 않고 지속적으로 클라이언트에게 컴포넌트를 보내줍니다. 이는 컴포넌트의 스트리밍과 상호작용을 가능하게 하고, 동적인 UI 업데이트와 서버-클라이언트 상호작용을 실현하는 데 도움이 됩니다.

Q. RSC는 Next.js와 같은 프레임워크에서 제공하는 SSR 기능 없이는 pre-rendering이 안되는 거지?

A. 네, RSC는 Next.js와 같은 프레임워크에서 제공하는 SSR(Server Side Rendering) 기능과 함께 사용되어 최적의 결과를 얻을 수 있습니다. RSC는 Next.js의 기능 중 하나로서, Next.js 프레임워크 내에서 동작하도록 설계되었습니다.

RSC는 서버 측에서 컴포넌트를 실행하고 초기 데이터를 전달하기 위해 SSR을 사용합니다. Next.js는 이러한 SSR 기능을 제공하여 컴포넌트를 서버에서 렌더링하고 초기 상태를 생성하여 클라이언트에 전달할 수 있게 합니다.

따라서 RSC를 사용하기 위해서는 Next.js 프레임워크에서 제공하는 SSR 기능을 사용해야 합니다. RSC를 통해 서버에서 컴포넌트를 실행하고 초기 데이터를 전달하는 과정은 SSR을 통해 이루어집니다. SSR을 사용하지 않는 경우에는 RSC를 활용하여 컴포넌트의 pre-rendering이 어렵거나 불가능할 수 있습니다.

결론적으로, RSC를 사용하기 위해서는 Next.js와 같은 SSR을 제공하는 프레임워크 내에서 활용되며, SSR을 통해 컴포넌트의 pre-rendering을 수행할 수 있습니다.

mochang2 / development-diary

React Server Component #8