DEV Community: Ray Kim

React SSR 아키텍처 - Render Server

Ray Kim — Thu, 31 Dec 2020 02:50:38 +0000

SSR을 할 경우 리액트 빌드 서버(또는 클라이언트용 웹팩)와 별개로 사용자 요청을 받아 알맞는 리액트 앱을 응답하는 렌더링용 서버가 필요하다.

렌더링용 서버에선 ReactDOMServer.renderToString 등의 기본 메서드를 통해 리액트를 간단히 SSR할 수 있었지만, 이는 Node.js(또는 JavaScript runtime) 서버 위에서 작동한다.

즉, React SSR을 할 경우 Node.js 서버가 가장 알맞은 선택일 것이다.

그렇다면 효율적인 SSR 서버 구현에 대해 생각해보자.

계층화

SSR 웹 앱을 백엔드 서버와 렌더링 서버로 분리할 수 있다고 보자.

이렇게 계층화를 이룰 경우, 렌더링 서버를 추상화 및 스케일아웃할 수 있으며, 백엔드의 여러 서비스를 프록시를 통해 적재적소에 이용할 수 있다.

![계층화](https://dev-to-uploads.s3.amazonaws.com/i/1v2hjqipinli7999zx7f.png) \

그렇다면 렌더링 서버에 어떤 기능을 포함해야 할까? 막상 계층화를 이뤘다고 해도, 백엔드 서버와 렌더링 서버의 경계는 모호할 수밖에 없다.

먼저 관심사 분리를 명확히 한 렌더링 서버는 오로지 rendering에 집중한다고 가정하자.

// Express.js 예시

function renderer(req) {
  const App = <MyApp />;

  const content = renderToString(App);

  return `
    <html>
      <body>
        <div id="app">${content}</div>
        <script src="bundle.js"></script>
      </body>
    </html>
  `;
}

const app = express();

// 사용자가 요청할 `bundle.js`의 경로
app.use(express.static('public'));

// 모든 path에 대한 동일 `renderer` 처리한다: `req` 오브젝트를 사용해 렌더링한다.
app.get('*', (req, res) => {
  const content = renderer(req);

  res.send(content);
});

위 예시처럼 모든 path('*')에 대해 같은 콜백을 넘겨주자. 이는 req 객체만을 사용해 렌더링하겠다는 의미이며, 콜백 내부에 렌더링 로직이 들어간다.

물론 MPA일 경우 페이지별로 라우터를 관리할 수도 있지만, 라우팅은 추후 react-router이 관여하므로 모든 path에 대한 처리를 동일하게 한다.

마지막으로 express.static('public') 미들웨어를 사용하는 이유는 지난 포스트에서 다룬 것과 같이 SSR 후 사용자가 bundle.js를 추가적으로 요청할 때, 미리 번들링한 파일을 넘겨주는 용도이다.

라우팅

react-router 라이브러리의 BrowserRouter은 브라우저의 location 변화를 감지하여 지정된 라우터에 따라 컴포넌트를 렌더링해준다. 특이한 점은 history.pushState를 사용하여 브라우저 location을 리로딩 없이 변경해준다는 것이다. 즉, 브라우저 상태변화에 따라 새로운 요청이나 리로딩 없이 UI를 변화시켜준다.

하지만 서버에선 브라우저와 달리 location 변화가 일어나지 않으며, 오로지 요청(req 객체의 path)에 대한 라우팅만 가능하다. 또한 location 변화에는 유저 interaction이 필요하며, 서버에서 req만으로 interaction을 감지할 수는 없다.

앞서 다뤘듯 렌더링 서버는 app.get('*', () => {})을 통해 모든 path에 대한 같은 렌더링 로직을 사용한다. 이런 구조를 변경하여 path에 따라 일일이 렌더링 로직 및 리액트 앱을 관리하기엔 isomorphic 구조를 유지하기도 어렵고 비효율적이다.

그렇다고 BrowserRouter 컴포넌트를 바로 보낸다는 것은 클라이언트에게 렌더링을 맡긴다는 의미이다. 브라우저 location 변화를 기준으로 UI를 관리하는 BrowserRouter는 결국 리액트 앱의 일부분일 뿐이며 bundle.js에 포함된다.

그렇다면 원하는 URL에 따라 서버에서 렌더링하여 사용자에게 줄 수 있는 방법이 필요할 것이다. 이 때 사용하는 SSR용 라우터가 바로 StaticRouter이다.

다음 예시를 보자.

// 렌더링 서버 코드

function renderer(/* Express Request */ req) {
  // `StaticRouter`은 제공된 경로(req.path)를 기반으로 렌더링한다.
  const App = (
    <StaticRouter location={req.path}>
      <MyRoutes />
    </StaticRouter>
  );

  const content = renderToString(App);

  return `
    <html>
      <body>
        <div id="app">${content}</div>
        <script src="bundle.js"></script>
      </body>
    </html>
  `;
}

StaticRouter은 req.path를 기반으로 리액트 앱을 빌드한다. 이를 이용하면 location 변화에 따른 UI 업데이트가 아닌 처음부터 URL 입력값을 기준으로 렌더링된 HTML을 만들어 줄 수 있다.

하지만 여전히 클라이언트는 BrowserRouter을 사용하는 것이 타당하다. 이미 렌더링된 앱에선 새로운 페이지를 로드하는 것이 아닌 상태 변화에 따라 UI를 변경하는 것이 더 효율적이기 때문이다.

![Router](https://dev-to-uploads.s3.amazonaws.com/i/lsiy9ocj2cwnemzd82vh.png) \

리소스(bundle.js)는 앱 로딩 후 이미 가져온 상태이기 때문에 BrowserRouter의 사용제한이 없으며 클라이언트가 렌더링을 담당하게 된다.

// 클라이언트 코드

const App = (
  <BrowserRouter>
    <MyRoutes />
  </BrowserRouter>
);

ReactDOM.hydrate(App, document.getElementById('app'));

ReactDOM.hydrate는 이런 차이를 인지하고, Router 내부의 코드를 알맞게 hydration하므로 StaticRouter(서버)과 BrowserRouter(클라이언트)을 교차 사용하는 것이 가능하다.

번들링

실제로 여기까지 시도해봤다면 서버에서 JSX를 렌더링하지 못한다는 것을 알 수 있다.

하지만 이는 클라이언트도 마찬가지다. 클라이언트에서 JSX를 '사용'할 수 있는 것처럼 보이는 것은 사실 번들러가 Babel을 이용해 JSX를 트랜스파일하기 때문이다.

그렇다면 서버의 코드도 마찬가지로 번들러와 Babel을 통해 Node.js가 인식할 수 있는 코드로 번들링되어야 한다.

이 때, 서버의 웹팩은 target: 'node'이 되어있어야 하며, isomorphic한 리액트앱을 위해 JSX에 관여하는 Babel 설정은 서버와 클라이언트가 동일해야 한다. [참고]

![렌더링 서버와 라우터](https://dev-to-uploads.s3.amazonaws.com/i/jd6q1yn9ltvsofgtgvog.png) \<렌더링 서버와 라우터\>

위와 같이 렌더링 서버 코드는 클라이언트 코드와 함께 번들링된다. 그 후 브라우저에서 페이지요청을 보내면 렌더 서버에서 StaticRouter를 통해 해당 path에 대한 앱(HTML)을 렌더링한 후 응답한다.

브라우저는 렌더링된 HTML을 받은 후, bundle.js를 Public에서 받아 hydration을 진행한다. 그리고 앱의 location을 바꿀 때 bundle.js의 BrowserRouter을 통해 UI를 업데이트한다.

React SSR 아키텍처 - Redux Integration

Ray Kim — Tue, 29 Dec 2020 22:36:01 +0000

리액트에서 공식적으로 지원하는 ReactDOM.hydrate 및 ReactDOMServer.renderToString을 통해 성공적으로 SSR된 리액트앱을 사용자에게 전달할 수 있었다. 하지만 이 방식으론 동적페이지가 아닌 상태가 존재하지 않는 간단한 페이지 밖에 렌더링하지 못한다.

상태관리 라이브러리인 Redux를 단순히 리액트 앱에 주입하면 될 것 같지만 SSR에선 store도 결국 서버에서 만들어야 한다.

preloadedState

서버에서 아무런 대응없이 상태를 주입한다면 클라이언트에서 새로운 요청을 할 때마다 새로운 상태를 만들 수밖에 없다.

이 말은 즉, 클라이언트에서 Redux 상태를 지지고 볶아도 새로운 요청을 보내면 페이지 상태가 초기화된다는 말이다.

// server code
function renderer(/* Express Request */ req) {
  // 매 요청마다 새로운 `store`이 만들어진다
  const store = createStore(/* reducers, preloadedState, enhancers */);

  const content = renderToString(
    <Provider store={store}>
      <App />
    </Provider>
  );

  return `
    <html>
      <body>
        <div id="app">${content}</div>
        <script src="bundle.js"></script>
      </body>
    </html>
  `;
}

문제의 해결 방법은 꽤나 직관적이다 - 서버에서 초기상태(preloadedState)를 관리하여 store을 만들어주면 된다.

이렇게 하면 store을 기반으로 리액트앱이 빌드되고, 위처럼 content를 통해 HTML에 주입된다.

하지만 역시나 문제가 생긴다. 바로 이 preloadedState가 클라이언트에게 없다는 것이다. preloadedState를 이용해 리액트앱을 서버에서 빌드하여 클라이언트에게 보내는 것까진 괜찮지만, 정작 클라이언트는 '상태'는 받고있지 않다.

클라이언트에 preloadedState가 없다면 서버와 클라이언트의 상태가 다르다는 것을 뜻하며, 상태가 다르니 만들어지는 리액트앱도 다르다. 즉, hydration 과정에 문제가 생긴다.

Redux 공식문서에서는 이 문제를 해결하기 위해 preloadedState를 JSON.stringify화 시켜 window 오브젝트에 주입하는 방법을 알려주고 있다.

return `
  <html>
    <body>
      <div id="app">${content}</div>
      <script>
        window.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState).replace(
          /</g,
          '\\u003c'
        )}
      </script>
      <script src="bundle.js"></script>
    </body>
  </html>
`;

replace(/</g>, '\\u003c')는 serialization을 위한 것

위와 같이 preloadedState(window.__PRELOADED_STATE__)를 HTML에 주입시킬 경우 클라이언트에서도 이를 이용한 store을 만들고 관리할 수 있다.

const store = createStore(
  /* reducers */,
  window.__PRELOADED_STATE__, // HTML에 주입된 preloadedState 이용
  /* enhancers */
);

ReactDOM.hydrate(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

Dynamic Configuration

서버에선 원하는 기본값 및 설정을 얼마든지 활용해 preloadedState를 만들 수 있으며, 이는 클라이언트 요청에 따라 변하는 동적페이지를 만들 수 있는 기반이 된다.

하지만 아직은 기본값(static configuration)으로 store을 만들고 있으며, 사용자는 요청과 무관하게 매번 새로운 상태를 받고 있다.

이를 해결하기 위해 활용할 수 있는 클라이언트의 HTTP request에는 params, cookies, body 등의 유의미한 정보가 담겨 있으며, 이를 토대로 사용자에 맞는 동적인 store을 만들 수 있다.

위 다이어그램을 보자. Express 서버에서 request를 활용하여 동적인 preloadedState(dynamic configuration)를 만들고, 이를 토대로 store을 만든다. 이를 이용해 리액트앱을 빌드하여 preloadedState(json)과 함께 HTML에 주입시켜 response로 보낸다.

이렇게 사용자 정보를 토대로 store을 만들 경우 서버는 클라이언트의 활동을 감지하여 리액트앱을 빌드할 수 있는 효과를 얻을 수 있으며, 사용자는 seemless한 UX를 경험할 수 있다.

Async Configuration

해결해야할 문제가 아직 더 남았다. 동적으로 상태를 만드는 것까지는 좋았지만, 비동기 처리는 어떻게 해야할까?

리액트 SSR에서 fetch와 같은 비동기 처리는 생각보다 복잡한 일이다.

이는 ReactDOMServer.renderToString의 동작 방식 때문인데,

React SSR 아키텍처 - Render Flow

Ray Kim — Fri, 18 Dec 2020 13:58:50 +0000

React SSR은 대체로 Next.js 프레임웍이 담당하는 추세이다. 하지만 좀 더 라이트하게 SSR을 하고 싶을 땐 어떻게 할까?

Next.js는 거대 프로젝트인 만큼 모두의 니즈에 맞출 수는 없으며, 대체로 엔터프라이즈용 기능이 out-of-the-box 탑재되어있다.

소프트웨어의 복잡도와 성능(컴퓨팅 속도의)은 상충관계이므로 가벼운 용도의 SSR 서버를 직접 만들어 보는 것도 좋은 접근일 것이다.

그렇다면 React SSR은 어떻게 설계해야 할까? 먼저 React의 작동 원리부터 생각해보자.

React Virtual DOM

Virtual DOM은 의미 그대로 가상으로 DOM을 관리하겠다는 말이다. 리액트 앱은 Virtual DOM을 메모리에서 관리하면서 상태 변화(diff)를 감지하여 브라우저 UI에 반영시킨다.

그런데 이 가상 DOM이 메모리에서 관리된다면, 브라우저가 아닌 서버 메모리에서 생성해도 될 것이다.

즉, 요청으로 받은 상태를 기반으로 서버 메모리에서 가상 DOM을 만들고, 이를 기반으로 한 HTML를 응답으로 보낸다면, 사용자는 SSR된 리액트 앱을 사용할 수 있다.

이것이 React SSR의 기본 개념이다.

사실 이 방식은 흔히 쓰이는 템플릿엔진을 이용한 SSR과 같고, 리액트를 템플릿으로 하여 만들어진 DOM을 HTML에 주입시키는 것으로 보면 된다.

![SSR](https://dev-to-uploads.s3.amazonaws.com/i/wpku7oq5kcb4psmft2cp.png) \<리액트를 뷰템플릿으로 한 SSR\>

이 과정을 그럼 브라우저와 서버의 통신 과정에서 정리해보자.

먼저, 브라우저가 서버에 요청을 보내면, 서버는 브라우저가 제공하는 정보(헤더, 상태 등)을 기반으로 가상DOM을 만든다.

이 DOM은 다음과 같이 서버에서 렌더된 후 그대로 HTML 템플릿에 주입되어 보내진다.

// Express.js 서버에서 React SSR을 만드는 과정

const App = <h1>Hello World!</h1>;

const content = renderToString(App); // 가상 DOM을 렌더링 후 string 반환

// 렌더링이 완료된 리액트 요소를 템플릿에 주입
const template = (content) => `
  <html>
    <body>
      <div id="app">
        ${content}
      </div>
      <script src="bundle.js"></script>
    </body>
  </html>
`;

res.send(content); // Express.js response 사용을 가정한다

리액트는 SSR을 염두해 ReactDOMServer.renderToString 등의 메서드를 제공하며, 이는 렌더링된 HTML string을 반환한다. (클라이언트의 ReactDOM.render을 대체한다)

그 후 실제 브라우저가 받는 응답은 다음과 같다.

<html>
  <body>
    <div id="app">
      <h1>Hello World!</h1>
    <div>
  </body>
  <script src="bundle.js"></script>
</html>

보다시피 리액트가 성공적으로 렌더링 된 것을 볼 수 있다!

그런데 <script> 번들은 어떻게 만들까?

아무리 서버에서 렌더링이 완료된 HTML를 가져왔어도, interactive한 UI를 사용하려면 당연히 JavaScript가 필요하다.

필수 패키지들을 효율적으로 번들링하여 가져올 수는 있지만, 이 번들에 리액트를 어떻게 포함시켜야 하는지가 관건이다.

즉, 리액트가 제대로 작동하기 위해 리액트 의존성을 번들링하는 것은 문제가 없지만 리액트 컴포넌트를 어떻게 관리할 것이냐에 대한 고민이 생긴다.

Isomorphic App

React SSR을 개발할 때 isomorphic 구조로 컴포넌트를 관리하는 것은 필수적이다.

Isomorohic의 사전적 의미는 '동일'이며 isomorphic 리액트 앱이라 함은 서버와 클라이언트의 컴포넌트 구조를 동일하게 관리하는 형태를 일컫는다.

이렇게 동일 구조를 유지하면 클라이언트에서 <script> 번들의 리액트앱을 렌더링 할 경우 ReactDOM은 이미 Paint가 완료된 SSR의 HTML과 번들의 가상DOM을 비교하여 리액트JS를 바인딩(또는 hydration)한다.

hydration 용도로 클라이언트는 ReactDOM.render 대신 ReactDOM.hydrate를 사용한다.

이 때, isomorphic하게 앱을 관리하지 않는다면 리액트는 진상을 부릴 것이고, 우리의 뜻대로 리액트가 바인딩되지 않을 것이다.

// 클라이언트의 리액트

const App = () => {
  // handler와 같은 JS 요소들이 hydration을 통해 corresponding component에 바인딩된다.
  const handler = () => {
    console.log('hydration success!');
  };

  return (
    <>
      <div>
        <h1>Misplaced Component</h1>
        <button onClick={handler}>Click Me!</button>
      </div>
    </>
  );
};

ReactDOM.hydrate(App, document.getElementById('app'));

// 서버의 리액트

// 클라이언트와 구조가 다르다
const App = (
  <>
    <h1>Misplaced Component</h1>
    <div>
      <button>Click Me!</button>
    </div>
  </>
);

const content = renderToString(App);

res.send(content);

위의 예시와 같이 클라이언트와 서버의 리액트 구조가 다르면 경우 컴포넌트(Virtual DOM 포함)가 다시 생성되거나 구조를 멋대로 해석해 기능이 제대로 작동하지 않는다.

미스매치에 대한 ReactDOM.hydrate의 대응은 safeguard로써 존재하지만, 이런 버그를 그냥 놔둔다면 퍼포먼스는 더 악화되며 SSR을 사용하는 의미가 없다.

SSR의 목표는 JS요청을 기다리기 전에 빠르게 HTML을 Paint하겠다는 것이다.
응답받은 HTML이 다시 렌더링 된다면 의미가 퇴색된다.

![Render Flow](https://dev-to-uploads.s3.amazonaws.com/i/qag2zxilrux02srysldz.png) \<기본적인 Render Flow\>

위 그림에서 브라우저는 첫 번째 요청↔응답에서 바로 마크업을 받아볼 수 있다.

그 다음 요청인 <script> 번들(bundle.js)은 대체로 HTML보다 사이즈가 훨씬 크다. 느린 네트워크 환경에선 먼저 렌더링된 UI부터 보는 것이 사용자경험에 이로울 것이다.

최종적으로 서버는 알맞은 번들을 보내고, 클라이언트는 React app을 바인딩하여 interactive한 기능을 사용할 수 있다.

Nest.js에서 Pipe의 필요성

Ray Kim — Thu, 17 Dec 2020 22:09:26 +0000

Nest.js의 Pipe는 굳이 비교하자면 Spring의 Converter 또는 Formatter의 그것과 같다.

하지만 Middleware나 helper가 있는데 왜 Pipe라는 개념까지 도입한 것일까라는 의문이 생긴다.

공식문서의 개념에서 Pipe는 @injectable decorator을 사용하는 JS class 라고 설명하고 있다. 즉, Provider과 기본 개념이 동일하다.

그렇다면 먼저 injectable이 무엇인지 알아보자.

Injectables

A모 프레임웍에서 에서 파생된 injectable은 간단히 말해 Dependency Injection 패턴을 적용시키겠다는 말이다.

Nest는 Provider 패턴으로 쉽게 dependency를 관리 및 공유할 수 있는데,
한 번의 주입으로 만들어진 의존성 인스턴스를 하위 모듈에서 쉽게 접근할 수 있다는 장점이 있다.

React Context Provider ∝ Nest Module Provider
하위 객체에게 의존성을 주입하는 것은 비슷하다.

이는 인스턴스 한 개만 관리하기 때문에 디버깅을 간단하게 해줄뿐만 아니라 메모리 누수를 막을 수 있다는 매우 큰 이점을 가져다 준다.

다음과 같은 예를 보자.

@Injectable()
export class ExampleService {
  constructor(private memoryLeak = new ArrayBuffer(10000)) {}
}
// ExampleService 인스턴스가 생성될 때마다 10000byte 메모리 누수를 일으킨다.

@Module({
  providers: [ExampleService],
})
export class ExampleModule {}
// 이를 `Injectable`화 하여 주입하면 Nest는 인스턴스를 재사용하게 된다.

이같이 한 번의 Provider 주입만으로 injectable을 하위 모듈간 쉽게 위임하고 재활용할 수 있다.

명시적 injectable을 통한 DI패턴은 유용하지만, 여기까지만 보면 그냥 필요에 따라 Provider에 헬퍼나 팩토리 따위를 담아 사용하는 방법이 떠오른다.

그렇다면 다시 처음으로 돌아가 Pipe는 타 헬퍼과 다른 점이 무엇일까?

Pipe vs. the World

공식문서를 인용하자면 Pipe는 컨트롤러 handler의 매개변수 전처리를 도와주는 특수한 helper라고 정의할 수 있다. 다시 말해 input으로 들어오는 데이터를 지정된 파이프를 거쳐 들어오게끔 하는 것이다.

이는 Middleware의 역할이 아닌가라고 볼 수 있지만 Middleware은 Request에 항상 관여한다면, Pipe는 특정 route handler에 붙어 필요한 데이터값만 선별해 다룬다는 점에 차이가 있다.

이렇게 Pipe를 거친 input을 handler에 전달할 경우 각 단일책임원칙을 위배하지 않음과 동시에 알맞게 정제된 반환값을 받을 수 있다.

또한, Pipe 역시 재사용 가능한 injectable이므로 어느 라우터에 갖다 붙여도 된다는 장점이 있다.

Pipe 또한 당연하게도 exception filter의 혜택을 누릴 수 있다. 특정 매개변수의 에러를 이곳에서 처리하자.

Pipe use-case

Pipe 역할은 이제 알디시피 '맞춤형' 필터라고 볼 수 있으며 평소 middleware이 하는 역할들을 pipe에게도 맡길 수 있을 것이다.

태생이 이렇다 보니, Nest 프레임웍은 자주 쓰이는 기본 Pipe들을 제공한다.

실전으로 들어가 REST API에서 /person/3 endpoint에 요청을 받았다고 생각해보자.

@Controller('person')
export class PersonController {
  @Get(':id')
  async getPerson(@Param('id') id: number) {
    // return a matching person
  }
}

이 때, id가 항상 number로만 들어오면 괜찮지만 만약 3a가 들어올 경우 Pipe를 제공해 변환해주어야 한다.

// ParseIntPipe에 변환 과정을 위임한다.
@Get(':id')
async getPerson(@Param('id', ParseIntPipe) id: number) {
  // return a matching person
}

이처럼 Pipe를 사용해 아주 간단히 getPerson handler의 관심사 분리를 할 수 있다.

Pipe용으로 사용할 수 있는 매개변수는 @Param, @Body, @Query가 있다.

위 예시는 기본적인 Pipe 사용 방법을 제시했지만, 유효성 검증 및 입맛에 따라 커스텀 Pipe도 얼마든지 만들 수 있다.