4장. 서버 사이드 렌더링

SPA vs SSR

• SPA
  • 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식
  • 최초에 서버에서 최소한의 데이터를 불러온 이후로부터는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 모든 작동이 이뤄짐
  • JAM(JavaScript, API, Makup) 스택 등장 ⇒ 서버 확장성 문제에서 자유로워짐
  • 장점 : 훌륭한 사용자 경험 제공 ← 한 번 로딩된 이후에는 서버를 거쳐 필요한 리소스를 받아올 일이 적어지기 때문
  • 단점 : 최초에 로딩해야 할 자바스크립트 리소스가 커짐
• SSR
  • 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식
  • 장점
    • 최초 페이지 진입이 비교적 빠름
    • 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉬움
    • 누적 레이아웃 이동이 적음 : 사용자가 예상치 못한 시점에서 페이지가 변경되어 불편을 초래하는 것
    • 사용자의 디바이스 성능에 비교적 자유로움
    • 좀 더 안전한 보안
  • 단점
    • 소스코드를 작성할 때 항상 서버를 고려해야 함
    • 적절한 서버가 구축돼 있어야 함
    • 서비스 지연에 따른 문제

SSR을 위한 리액트 API

• renderToString
  • 서버 사이드 렌더링을 구현하는 데 가장 기초적인 API
  • 인수로 넘겨받은 리액트 컴포넌트를 렌더링해 HTML 문자열로 반환하는 함수
  • 뛰어난 초기 렌더링 성능 ← 먼저 완성된 HTML을 서버에서 제공할 수 있으므로
  • 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉬움
  • data-reactroot : hydrate 함수에서 루트를 식별하는 기준점이 됨
• renderToStaticMarkup
  • renderToString 함수와 유사하지만, 리액트에서만 사용하는 추가적인 DOM 속성을 만들지 않는다는 차이가 있음
  • 리액트의 이벤트 리스너가 필요 없는 완전히 순수한 HTML을 만들 때만 사용됨
• renderToNodeStream
  • renderToString과 결과물이 완전히 동일
  • renderToString과 달리 브라우저에서 사용 불가능
  • 결과물의 타입이 ReadableStream으로 Node.js에서만 사용 가능
  • 스트림 : 큰 데이터를 다룰 때 데이터를 청크(chunk, 작은 단위)로 분할해 조금씩 가져오는 방식
• renderToStaticNodeStream
  • renderToNodeStream과 제공하는 결과물은 동일하나, 리액트 자바스크립트에 필요한 속성이 제공되지 않음
• hydrate
  • renderToString과 renderToNodeStream으로 생성된 HTML 콘텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할
  • reder와 인수를 넘기는 방식이 유사함
  • 이미 렌더링된 HTML을 기준으로 이벤트를 붙이는 작업만 실행 ↔ render : 빈 HTML에 정보를 렌더링
  • 서버에서 완성한 HTML과 하이드레이션 대상이 되는 HTML의 결과물이 동일한지 비교하며 렌더링 진행

Next.js

• Next.js의 _app.tsx과 _document.tsx의 차이

• next의 SSR과 CSR

  • 서버 라우팅 : 최초 페이지 렌더링이 서버에서 수행됨
  • 클라이언트 라우팅 : 내부 페이지 이동 방식
    • a 태그 대신 next/link를 통한 페이지 이동
    • window.location.push 대신 router.push 사용

• Data Fetching

  • pages/ 폴더에 있는 라우팅이 되는 파일만 사용할 수 있음
  • 예약어로 지정되어 반드시 정해진 함수명으로 export를 사용해 함수를 파일 외부로 내보냄
  • 서버에서 미리 필요한 페이지를 만들어 제공 가능
  • 해당 페이지에서 요청이 있을 때마다 서버에서 데이터를 조회해 미리 페이지를 만들어 제공할 수 있음