🎈 Chapter 6: 서버 사이드 렌더링

클라이언트 사이드 렌더링 한계

검색 엔진 최적화(SEO)

클라이언트 사이드 렌더링의 주요 한계 중 하나는 일부 검색 엔진 크롤러가 자바스크립트를 실행하지 않으며, 자바스크립트를 실행하는 크롤러도 예쌍대로 실행되지 않을 수 있기에 콘텐츠를 올바르게 색인하지 못할 수 있다는 것입니다.

성능

클라이언트에서 렌더링되는 애플리케이션은 느린 네트워크나 낮은 성능 기기에서 성능 문제를 겪을 수 있습니다. 콘텐츠를 렌더링하기 전에 자바스크립트를 다운로드하고, 구문 분석과 실행까지 해야 하기 때문에 콘텐츠 렌더링이 상당히 지연될 수 있습니다.
애플리케이션을 읽어 들이는 시간이 매우 오래 걸리면 사용자가 페이지를 떠날 수 있으며, 이는 검색 엔진의 페이지 순위에 부정적 영향을 미칠 수 있습니다.

클라이언트 전용 애플리케이션의 또 다른 문제는 네트워크 폭포 현상입니다. 이는 웹사이트나 웹 애플리케이션을 표시하기 위해 브라우저가 다운로드, 파싱, 실행해야 하는 자바스크립트 떄문에 초기 페이지 로드가 차단되는 현상을 말합니다.

서버 사이드 렌더링을 사용하면 사용자가 유용한 콘텐츠를 즉시 볼 수 있도록 개선할 수 있습니다.

보안

클라이언트 사이드 렌더링은 특히 민감한 데이터를 처리할 떄 보안이 문제시될 수 있습니다. 이는 애플리케이션의 모든 코드가 클라이언트의 브라우저로 다운로드되어 크로스 사이트 요청 위조(CSRF) 같은 공격에 취약하기 떄문입니다.

CSRF를 아주 깊이 알지 못해도 이를 방어할 수 있는데, 일반적인 방법은 웹사이트나 웹 앱을 사용자에게 제공하는 서버를 제어하는 것입니다. 이 서버를 제어할 수 있다면, 신뢰할 수 있는 출처인 서버에서 클라이언트로 적절한 CSRF 방지 토큰을 전송할 수 있습니다.

서버 렌더링의 부상

서버 렌더링의 장점

최초 의미 있는 페인트(first meaningful paint)가 완성되는 시간이 더 빨라집니다.

서버가 초기 HTML 마크업을 렌더링해 클라이언트로 전송하면 바로 콘텐츠를 볼 수 있기 때문입니다. 애플리케이션이 렌더링되기 전에 클라이언트가 자바스크립트를 다운로드, 파싱, 실행할 때까지 기다려야 하는 클라이언트 사이드 렌더링과 대조적입니다.

웹 애플리케이션의 접근성을 개선합니다
웹 애플리케이션의 SEO를 개선할 수 있습니다
웹 애플리케이션의 보안도 향상시킬 수 있습니다

그러나 서버에서 렌더링된 HTML은 정적이며 자바스크립트를 읽어 들이지 않은 상태이기에 상호 작용 지원이 부족합니다. 이벤트 리스너나 기타 동적 기능도 포함되지 않았습니다. 사용자 상호 작용을 비롯한 동적 기능을 활성화하려면, 필요한 자바스크립트를 정적 HTML에 촉촉하게 공급해 줘야 합니다. 하이트레이션을 해야 한다는 의미입니다.

하이드레이션

하이드레이션은 서버에서 생성되어 클라이언트를 전송되는 정적 HTML에 이벤트 리스너와 여러 자바스크립트 기능을 추가하는 프로세스를 의미하는 용어입니다. 하이드레이션의 목적은 브라우저가 서버 렌더링 애플리케이션을 읽어 들인 후 여기에 상호 작용을 추가해서 사용자에게 빠르고 원활한 경험을 제공하는 것입니다.
리액트 애플리케이션에서 하이드레이션은 클라이언트가 서버에서 렌더링된 리액트 애플리케이션을 다운로드한 후에 발생합니다. 이후에는 다음 단계로 진행됩니다.

클라이언트 번들 로딩

브라우저는 정적 HTML을 렌더링하는 동안 애플리케이션의 코드가 포함된 자바스크립트 번들을 다운로드하고 파싱합니다. 이 번들에는 리액트 컴포넌트와 애플리케이션의 기능에 필요한 코드가 포함되어 있습니다.

이벤트 리스너 추가

자바스크립트 번들이 로드되면 리액트는 이벤트 리스너 및 기타 동적 기능을 DOM 요소에 추가해 정적 HTML을 하이드레이션합니다. 이 동작은 일반적으로 react-dom 패키지의 hydrateRoot 함수를 사용해 수행되며, 이 함수는 루트 리액트 컴포넌트와 DOM 컨테이너를 인수로 받습니다. 하이드레이션이 완료되면 정적 HTML이 완전한 인터랙티브 리액트 애플리케이션을 변환됩니다.

하이드레이션 프로세스가 완료되면 애플리케이션은 완전히 인터랙티브하게 변해서 필요에 따라서 사용자 입력에 응답하고, 데이터를 가져오고, DOM을 업데이트합니다.

하이드레이션에 대한 비판

하이드레이션은 서버에서 렌더링된 HTML을 인터랙티브하게 만드는 좋은 방법이지만, 일부에서는 하이드레이션이 필요 이상으로 느리다고 비판하며 재개 가능성을 더 나은 대안으로 꼽기도 합니다.

하이드레이션을 사용하면 서버에서 리액트 애플리케이션을 먼저 렌더링한 다음 렌더링된 출력을 클라이언트에 전달합니다. 하지만 이 시점까지는 인터랙티브한 기능이 없습니다. 이후 브라우저는 클라이언트 번들을 다운로드하고 이벤트 리스너를 추가한 후 클라이언트를 효과적으로 '리렌더링'해야 합니다. 많은 작업을 필요로 하며 때로는 콘텐츠가 사용자에게 표시되는 시점과 사용자가 실제로 사이트를 사용할 수 있는 시점 사이에 지연이 발생할 수 있습니다.

재개 가능성을 활용하면 전체 애플리케이션이 서버에서 렌더링되어 브라우저로 스트리밍됩니다. 초기 마크업과 함께 모든 인터랙티브 동작이 직렬화되어 클라이언트로 전송됩니다. 이 시점에서 클라이언트는 이미 인터랙티브해지는 방법에 대한 모든 정보를 가지므로 서버가 중단한 부분부터 다시 시작할 수 있습니다. 하이드레이션(즉, 이벤트 리스너를 연결하고 클라이언트 사이드에서 페이지를 렌더링)할 필요 없이 서버가 제공한 내용을 역직렬화해 그에 따라 반응할 수 있습니다. 하이드레이션 단계를 건너뛰면 인터랙티브 시간(TTI)이 짧아지고 시용자 경험이 향상될 수 있습니다.

서버 렌더링 작성

클라이언트 전용 리액트 앱에 서버 렌더링을 수동으로 추가하기

// server.js

// 필요한 모듈 가져오기
const express = require("express");
const path = require("path");
const react = require("react");
// 서버 사이드 렌더링을 위해 ReactDOMServer 가져오기
const ReactDOMServer = require("react-dom/server");

const App = require("./src/App");

const app = express();

// 'build' 디렉터리에 있는 정적 파일 서빙하기
app.use(express.static(path.join(__dirname, "build")));

// 모든 GET 요청 처리
app.get("*", (req, res) => {
  // App 컴ㅁ포넌트를 렌더링해 HTML 문자열을 생성합니다.
  const html = ReactDOMServer.renderToString(<App />);

  // 렌더링된 App 컴포넌트가 포함된 HTML 응답을 전송합니다.
  res.send(`
    <!DOCTYPE html>
    <html>
      <head>
        <title>예시 리액트 애플리케이션</title>
      </head>
      <body>
        <!-- 렌더링된 App 컴포넌트를 여기에 삽입 -->
        <div id="root">${html}</div>
        <!-- 메인 자바스크립트 번들을 연결 -->
        <script src="/static/js/main.js"></script>
      </body>
    </html>
  `);
});

app.listen(3000, () => {
  console.log("Server listening on port 3000");
})

이 예시에서는 Express를 사용해 ./build 디렉터리에서 정적 파일을 서비스하는 서버를 생성한 다음, 서버에서 리액트 앱을 렌더링합니다. 또 ReactDOMServer를 사용해 리액트 앱을 HTML 문자열로 렌더링한 다음, 클라이언트로 전송되는 응답에 삽입합니다.

하이드레이션

하이드레이션의 목적은 서버에서 렌더링된 애플리케이션을 브라우저에서 완전히 인터랙티브하게 만드는 것입니다.

import React from "react";
import { hydrateRoot } from "react-dom/client";
import App from "./App";

hydrateRoot(document, <App />);

리액트의 서버 렌더링 API

`renderToString`

renderToString은 리액트에서 제공하는 서버 사이드 렌더링 API로, 서버에서 리액트 컴포넌트를 HTML 문자열로 렌더링할 때 사용합니다. renderToString은 성능, SEO, 접근성을 개선하기 위해 서버에서 리액트 애플리케이션을 렌더링할 때 주로 사용합니다.

renderToString은 흐름을 가로막는 동기식 API이므로 실행이 중단되거나 일시적으로 중지될 수 없습니다. 대상이 되는 컴포넌트가 루트에서 몇 단계 깊이에 있다면, 처리하는 시간이 어느 정도 걸릴 수 있습니다.

renderToString은 유리한 장점이 많지만 불리한 단점도 몇 가지 있습니다.

성능
- renderToString의 주요 단점 하나는 대규모 리액트 애플리케이션에서는 처리 속도가 느릴 수 있다는 것입니다. 동기식이기 때문에 이벤트 루프를 차단하고 서버가 응답하지 않게 만들 수 있습니다.
스트리밍 지원 부족
- renderToString은 스트리밍을 지원하지 않으므로 클라이언트로 전송하려면 HTML 문자열 전체를 생성해야 합니다. 이로 인해 첫 번째 바이트 시간(TTFB)이 느려지고 클라이언트가 HTML 수신을 시작하기까지 더 오랜 시간이 걸릴 수 있습니다.

`renderToPipeableStream`

renderToPipeableStream은 리액트 18에 도입된 서버 사이드 렌더링 API로, 대규모 리액트 애플리케이션을 Node.js 스트림에 렌더링하는 보다 효율적이고 유연한 방법입니다. 이 API는 응답 객체로 파이프할 수 있는 스트림을 반환하며, HTML이 렌더링되는 방식을 더 세밀하게 제어할 수 있어서 더 쉽게 다른 Node.js 스트림과 통합할 수 있습니다.
또한 리액트의 동시성 기능, 특히 서버 사이드 렌더링 중 비동기 데이터 페치를 더 잘 처리해주는 Suspense를 완벽하게 지원합니다. 스트림이기 때문에 네트워크를 통해 스트리밍할 수 있으며, HTML 청크를 클라이언트에 비동기적으로 전송할 수 있어서 네트워크 지연 없는 점진적인 데이터 전달이 가능합니다.

// server.js

// 필요한 모듈 가져오기
const express = require("express");
const path = require("path");
const react = require("react");
// 서버 사이드 렌더링을 위해 ReactDOMServer 가져오기
const ReactDOMServer = require("react-dom/server");

const App = require("./src/App");

const app = express();

// 'build' 디렉터리에 있는 정적 파일 서빙하기
app.use(express.static(path.join(__dirname, "build")));

// 모든 GET 요청 처리
app.get("*", (req, res) => {
  const { pipe } = ReactDOMServer.renderToPipeableStream(<App />, {
    // 데이터를 페치하기 전에 앱이 준비되는 경우
    onShellReady: () => {
      // 서버가 HTML을 보낼 거라고 클라이언트에 통지
      res.setHeader("Content-Type", "text/html");
      pipe(res); // 리액트 스트림의 출력 결과를 응답 스트림에 파이프
    }
  })
});

app.listen(3000, () => {
  console.log("Server listening on port 3000");
})

renderToPipeableStream의 변환 결과는 HTML 문자열이 아니라 Node.js 스트림이 됩니다. 스트림을 사용하면 전체 데이터를 메모리에 한꺼번에 읽어 들이는 대신 청크 단위로 점진적으로 처리합니다. 이러한 접근 방식은 메모리에 모두 읽어 들일 수 없거나 네트워크를 통해 한번에 전송하지 못하는 대용량 문자열이나 데이터 스트림을 다룰 때 특히 유용합니다.

리액트는 서버에서 렌더링한 애플리케이션의 첫 번째 바이트 시간(TTFB) 지표를 개선하기 위해 리액트 컴포넌트를 쓰기 가능 스트림으로 스트리밍합니다. 이를 통해 HTML 마크업 전체가 생성될 때까지 서버가 기다렸다가 클라이언트에 전송하는 대신, HTML 응답 청크가 준비되는 즉시 전송을 시작해 전반적인 지연 시간을 줄입니다.

`renderToReadableStream`

브라우저 스트림은 웹 브라우저 내의 클라이언트 환경에서 작동하도록 설계되었으며, 주로 네트워크 요청, 미디어 스트리밍, 브라우저의 데이터 처리 작업에서 스트리밍 데이터를 처리합니다. 브라우저 스트림은 웹 전체의 API 표준화를 목표로 하는 WHATWG에서 정의한 스트림 표준을 따릅니다. Node.js 스트림과 달리 브라우저 스트림은 read(), write(), pipeThrough() 등의 메서드를 사용해 데이터의 흐름을 제어하고 스트리밍된 데이터를 처리합니다. 또 보다 표준화된 프라미스 기반 API를 제공합니다.

Node.js 스트림과 브라우저 스트림은 모두 스트리밍 데이터 처리를 목적으로 하지만, 동작하는 환경이 다르며 각 환경이 따르는 API와 표준도 조금씩 다릅니다. Node.js 스트림은 이벤트 기반이며 서버 측 작업에 적합한 반면, 브라우저 스트림은 최신 웹 표준에 따라 프라미스 기반이며 클라이언트 측 작업에 맞게 조정되었습니다.

두 환경 모두 지원하기 위해 리액트에는 Node.js 스트림용 renderToPipeableStream과 브라우저 스트림용 renderToReadableStream 함수가 있습니다. renderToReadableStream API는 renderToPipeableStream과 유사하지만 Node.js 네이티브 스트림 대신 브라우저에서 읽을 수 있는 스트림을 반환합니다.

클라이언트 사이드 렌더링 한계​

검색 엔진 최적화(SEO)​

성능​

보안​

서버 렌더링의 부상​

서버 렌더링의 장점​

하이드레이션​

하이드레이션에 대한 비판​

서버 렌더링 작성​

클라이언트 전용 리액트 앱에 서버 렌더링을 수동으로 추가하기​

하이드레이션​

리액트의 서버 렌더링 API​

renderToString​

renderToPipeableStream​

renderToReadableStream​

클라이언트 사이드 렌더링 한계

검색 엔진 최적화(SEO)

성능

보안

서버 렌더링의 부상

서버 렌더링의 장점

하이드레이션

하이드레이션에 대한 비판

서버 렌더링 작성

클라이언트 전용 리액트 앱에 서버 렌더링을 수동으로 추가하기

하이드레이션

리액트의 서버 렌더링 API

`renderToString`

`renderToPipeableStream`

`renderToReadableStream`