천재 해커 등장.
4. 서버 사이드 렌더링
해당 장에서는 리엑트를 이용한
SSR(Server-Side Rendering)에 대해 알아봄.
✨서버사이드 렌더링이란?
왜 SSR에 대해 배워야할까?
SSR코드는SPA를 만드는 것 보다 신경 쓸 점이 많음.
SSR이 왜 필요한지 배우지 못하면 일련의 작업들이 귀찮게만 느껴질 수 있다.
🔻싱글 페이지 애플리케이션의 세상
싱글 페이지 애플리케이션이란?
렌더링과 라우팅에 필요한 대부분의 기능을
브라우저의 자바스크립트에 의존하는 방식을 의미.
SSR과 SPA는 상반되는 개념.
▲하나의 페이지에서 모든 작업을 처리함
왜 싱글 페이지 라는 이름이 붙었을까?
최초에 첫 페이지에서 데이터를 모두 불러온 이후에는 페이지 전환을 위한 모든 작업이 자바스크립트와 브라우저의
history.pushState와history.replaceState로 이루어지기 때문에 페이지를 불러온 이후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리함.
SPA HTML 코드를 들여다보면
정상 작동하는 SPA HTML 코드를 들여다보면 내부에 아무런 내용이 없음. 이는 사이트 렌더링에 필요한 <body/> 내부 내용을 모두 자바스크립트 코드로 삽입한 이후에 렌더링 하기 떄문임.
최초에 서버에서 최소한의 데이터를 불러온다.
- 다음 페이지의 렌더링에 필요한 정보만 가져옴,
<body/> 내부 DOM을 추가,수정,삭제하는 방식의 페이지가 전환.- 서버에서 최초 데이터를 불러온 이후부터는 이미 가지고 있는 데이터를 기반으로 거의 모든 기능이 작동.
- 자바스크립트 리소스가 커지는 단점
- 한 번 로딩된 이후에는 서버에서 리소스를 받아올 일이 적어짐(훌륭한 UI/UX를 제공한다는 장점)
전통적 방식
- 페이지 전환이 발생할 때마다 새롭게 페이지를 요청
- HTML 페이지를 다운로드해 파싱하는 작업을 거침
- 페이지를 처음부터 새로 그려야 해서 일부 사용자는 페이지가 전환될 때 부자연스러운 모습을 보게 됨.
SPA 유행 이유
- React,Vue 등의 등장과 함께
자바스크립트의 의존도가웹페이지 전역으로 확장되면서 이를 모두 아우를 수 있는 방식인SPA가 인기를 얻게 됨.
JAM 스택
JAM stack은 JavaScript와 API 그리고 Markup(HTML) 만으로 이루어진 웹의 구성
AM stack에서 정의한 각자의 역할
- JavaScript
Client의 모든 처리는 Javascript 에게 맡김. - API
모든 기능 및 비즈니스 로직은 재사용 가능한 API 로 추상화. - Markup
SSG 나 Template Engine (Webpack 등) 을 이용하여 Markup 을 미리 생성.
🔻서버 사이드 렌더링
SSR > SPA > SSR
- SPA의 성능 문제를 해결하기 위해 서버 사이드 렌더링(SSR)이 다시 주목받고 있다.
- SPA : 사용자에게 제공되는 번들에서 렌더링 담당.
(로컬 기기에 영향을 받음 = 성능 보장 X)- SSR : 렌더링에 필요한 작업을 모두 서버에서 수행
(서버에서 렌더링 제공 = 안정적인 성능 보장)
SSR 장점
- 최초 페이지 진입이 비교적 빠름
- 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다
- 누적 레이아웃 이동이 적음
- 사용자의 디바이스 성능에 비교적 자유로움
SSR 단점
- 소스코드를 작성할 때 항상 서버를 고려해야 함
- 적절한 서버가 구축되어 있어야 함
- 서비스 지연에 따른 문제
현대의 서버사이드 렌더링
현대 SSR은 이전 LAMP 스택에서 표현했던 방식과 조금 다름
LAMP 스택은 모든 페이지 빌드를 서버에서 렌더링해 초기 페이지 진입이 빠르다는 장점이 있지만, 이후에 라우팅이 발생할 때도 마찬가지로 서버에 의존해야 하기 때문에 싱글 페이지 렌더링 방식에 비해 라우팅이 느리다는 단점이 있음.
그래서 요즘의 서버 사이드 렌더링은 이 두가지 장점을 모두 취한 방식으로 작동한다.
최초 웹사이트 진입시에는 서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동한다.
🔻SPA와 SSR을 모두 알아야 하는 이유
SSR 또한 모든 문제의 해결책이 될 수는 없음.
따라서 모든 방법론을 이해할 필요가 있음.
✨서버 사이드 렌더링을 위한 리액트 API
🔻renderToString
인수로 넘겨받은 리액트 컴포넌트 렌더링해 html 문자열로 반환하는 함수.
🔻renderToStaticMarkup
renderToString과 매우 유사한 함수.
두 함수 모두 리액트 컴포넌트를 기준으로 HTML 문자열을 만든다는 점에서 동일함. 한 가지 유의미한 차이점은 앞서 루트 요소에 추가한 data-reactroot 와 같은 리액트에서만 사용하는 추가적인 DOM 속성을 만들지 않는다는 점.
🔻renderToNodeStream
renderToString 과 같은 결과물이 완전히 동일하지만 두 가지 차이점이 있음.
01. 앞에서 살펴본 두 API인 renderToString & renderToStaticMarkup 은 브라우저에서 실행될 수 있지만, renderToNodeStream 은 실행이 불가능함.
🔻renderToStaticNodeStream
renderToString에 renderToStaticMarkup이 있다면
renderToNodeStream 에는 renderToStaticNodeStream이 있다. renderToNodeStream 과 제공하는 결과물은 동일하나, renderToStaticMarkup 과 마찬가지로 리액트 자바스크립트에 필요한 리액트 속성이 제공되지 않음.
🔻hydrate
hydrate 함수는 앞서 살펴본 두 개의 함수.
renderToString 과 renderToNodeStream 으로 생성된 HTML 콘텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할을 함. renderToString 의 결과물은 단순히 서버에서 렌더링한 HTML 결과물로 사용자에게 무언가 보여줄 수 있지만, 사용자가 페이지와 인터랙션하는 것은 불가능함.
천재 해커.