[Bun 시리즈] #3 Bun + React 조합으로 서버사이드 렌더링 구현하기

 

 

 

 

 

백엔드 개발자라면서요? 근데 왜 프론트 영역 공부하세요?

 

Bun http 통신에 대해 알아보다가 우연히 <Bun과 React로 서버사이드 렌더링 구현하기> 라는 게시물을 보게됐다.

(님아 그 강을 넘어가지 마시요...)

 

우선 Bun은 런타임이고 React는 라이브러리이기 때문에 Bun으로 React를 이용해서 프론트를 구축할 수 있다!

즉, 내가 찾은 글은 프론트 개발자 분들에게 좋을 글이었다.

나의 경우 프론트와 백이랑 같이 하는거라고 착각한거였다 🥹 ...

(Bun을 순간적으로 백 프레임워크라고 생각함)

(왜 React가 프레임워크가 아니라 라이브러리인지에 대해서는 따로 정리하겠다 - 런타임 vs 프레임워크 vs 라이브러리)

 

아무튼 나의 착각 덕분에 프론트 영역을 많이 공부하게 돼서 잘 정리해 봤다.

 

 

 

 

 

서버사이드 렌더링이란

 

따라하기에 앞서 서버사이드 렌더링이 무엇인지 알고가자.

백엔드 개발한지 2년 정도 됐는데 서버사이드 렌더링은 처음 들어봤다.

화면을 서버에서 그린다는거에 흥미로움을 느껴버렸다 😋

 

 

 

어디서 화면에 보일 페이지의 내용을 그리냐(=렌더링)에 따라 서버사이드 렌더링(=SSR), 클라이언트사이드 렌더링(=CSR)으로 나뉜다.

SSR은 서버에서 페이지의 내용을 다 그려서 브라우저에 던진다.

CSR은 페이지이 내용을 브라우저에서 그린다.

 

지금까지 내가 한 프론트는 다 CSR이었던 것이다.

그런데 지금까지 CSR로 해도 불편함을 느낀점이 없었다.

SSR을 왜 하는걸까? 🤔

 

두가지 이유가 있다.

1. 검색엔진 최적화(=SEO) 가능

2. 빠른 페이지 렌더링

 

개인적으로 첫번째 이유가 가장 큰 것 같았다.

아무래로 검색 사이트에 검색했을 때 결과가 사용자에게 많이 노출되면 좋은 서비스가 있을 수 있다.

CSR의 경우 검색엔진 최적화가 불리하다고 한다.

 

 

+) SSG

SSR에 찾아보니 SSG가 많이 보여서 함께 정리했다.

Static Site Generator로 정적 페이지 생성기다.

해당 페이지에 대한 요청이 발생하면 페이지를 재성성하는 것이 아닌 이미 생성된 페이지를 반환하는 형태로 동작한다.

 

SSR의 경우 항상 최신 상태를 유지해야 하는 경우에 쓰면 된다.

SSG의 경우 제품 상세 페이지와 같은 변할 일이 거의 없을 경우 쓰면 된다.

둘 다 서버 측에서 미리 렌더링 해주는 건 맞지만 Build Time 때 할 것인가(=SSG), Run Time 때 할 때인가(=SSR)에 따라 갈린다.

 

그...그만...죽여줘ㅓㅓㅓ...

후... 웹개발 너무 알게 많아서 피곤해

진짜 프론트 개발자 안하길 잘했다.

SSR 하나 파고 들었다가 지금 SSG, CSR, NextJS까지 머리 터질 것 같다.

 

 

 

 

여기서 잠깐!) React는 기본적으로 CSR이라는데요?

 

제목에도 써놨지만 React와 Bun으로 SSR을 하기로 했다.

근데 찾아보니 React는 대표적인 CSR이라고 한다...?

 

으아아악 진짜 그만해 ㅠㅠㅠㅠ

두번째로 멘붕이 왔는데 진정하고 알아보도록 하자.

 

React는 기본적으로 브라우저에서 실행되고, 동적으로 콘텐츠를 생성하여 사용자 인터페이스를 조작한다.

모든 렌더링이 사용자의 브라우저에서 이루어지기 때문에 CSR이다.

프론트 서버는 초기 요청에서 HTML과 JavaScript를 제공하는 역할을 할 뿐 그 이후 렌더링은 클라이언트에서 처리한다.

 

그렇다고 React를 이용해서 SSR을 못하냐 하면 아니다 ❗️

React의 기본 동작이 CSR라는 것 뿐이지 SSR을 지원해준다.

ReactDOMServer로 SSR을 구현하면 된다.

(예제의 내용이기 때문에 아래에 더 자세히 적어두었다.)

 

더 편하게 SSR을 구현하는 방법도 있다.

React 기반으로 구축된 *NextJS를 사용할 경우 SSR 혹은 SSG을 사용할 수 있다.

React에서 직접 생성하고 설정해 주었던 것들이 Next에선 이미 만들어져 있으니 편하고 개발 속도가 빠르다.

* NextJS
프론트, 백 사이드 모두 사용할 수 있는 풀스텍 프레임워크다.
React를 사용하여 사용자 친화적인 웹어플리케이션 및 정적 웹 사이트를 빠르게 개발 할 수 있다.

렌더링과 페이지 최적화 등 프론트 사이드에 취중되어져 있어 백 사이드 서버로 사용하는건 비추한다.
(정~말 간단한 프로젝트라면 NextJS로 후딱 만들어도 될듯)

 

 

최종적으로 내가 프론트 스펙을 정한다고 하면 검색엔진을 고려하는 가에 따라

Yes일 경우 Bun + Next의 SSR or SSG 

No일 경우 Bun + React의 조합으로 쓸 것 같다.

 

 

 

 

예제 따라하기

SSR 때문에 멀리 돌아온거 같지만 🤣🤣🤣

예제를 따라해보기로 하자.

 

bun init로 새 프로젝트 하나를 만들어준다.

 

bun add react react-dom
bun add @types/react-dom -d

그 다음 react를 추가한다.

(이 세상 속도가 아닌 bun 폼 미쳤다잉)

 

mv index.ts index.tsx

갑분 JSX로 전환하라고 한다.

이렇게 해야지 JSX 요소를 직접 반화할 수 있다고 한다.

 

// components > Pokemon.tsx
function Pokemon() {
  return <div>Bun Forrest, Bun!</div>;
}

export default Pokemon;

// index.tsx
import { renderToReadableStream } from "react-dom/server";
import Pokemon from "./components/Pokemon";

Bun.serve({
  async fetch(request) {
    const stream = await renderToReadableStream(<Pokemon />);

    return new Response(stream, {
      headers: { "Content-Type": "text/html" },
    });
  },
});

console.log("Listening ...");

 

아주 간단하게 만들어봤다. 

react-dom/server의 renderToReadableStream을 이용해서 react로 만들어놓은 페이지를 불러왔다. 

 

개인적으로 리액트 CSR보다 SSR이 더 취향에 맞았다.

코드만 봐도 간결하고 한 눈에 들어와서 좋다.

이렇게 하니깐 html이나 JSX를 안봐서 너무 좋다 🤣

(< > 👈 이거 짱시룸)

 

예제에 동적 라우팅도 나오는데 유심히 볼 곳은 딱히 없다.

해보면서 느낀건 프론트 개발자들이 서버까지 다뤄야 한다는게 리스크이면서 메리트일 수 있겠다 싶었다.

(아무튼 서버긴 서버니깐)

 

 

 

다음엔 정말 서버단의 http 통신 다뤄야지.

 

 

 

 

 

 

 

 

fin.