4.1 서버 사이드 렌더링이란?
4.1.1 싱글 페이지 애플리케이션의 세상
-
싱글 페이지 애플리케이션이란?
사이트 렌더링에 필요한 HTML의 body 내부 내용을 모두 자바스크립트 코드로 삽입한 이후에 렌더링
페이지 전환 시에도 자바스크립트에서 렌더링에 필요한 정보만 HTTP 요청 등으로 가져온 다음, 그 결과를 body 내부에 DOM을 추가, 수정, 삭제하는 방법으로 전환=> 즉, 최초에 서버에서 최소한의 데이터를 불러온 이후에는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 모든 작동이 이뤄진다.
=> 최초에 자바스크립트 리소스가 커지는 단점이 있지만 한번 로딩된 이후에는 서버를 거쳐 필요한 리소스를 받아올 일이 적어지기 때문에 사용자에게 훌륭한 UI/UX를 제공할 수 있음
-
싱글 페이지 렌더링 방식의 유행과 JAM 스택의 등장
기존의 웹 개발은 LAMP 스택, Linux(운영체제), Apache(서버), MySQL(데이터베이스), PHP/Python 등(웹 프레임워크)으로 구성돼 있었다.=> 과거에는 자바스크립트에서 할 수 있는 일이 제한적이기 때문
Backbone.js, AngularJS, Knockout.js 등 자바스크립트에서 MVx 프레임워크를 구현할 수 있게 되면서 JAM(JavaScript, API, Markup) 스택이 등장
=> 대부분 작업이 자바스크립트에서 수행할 수 있었기 때문에 프론트엔드는 자바스크립트와 마크업(HTML, CSS)을 미리 빌드해 두고 정적으로 사용자에게 제공하여 서버 확장성 문제에서 좀 더 자유로워질 수 있게 됨
--> API 서버 자체도 자바스크립트로 구현하는 구조가 나옴
4.1.2 서버 사이드 렌더링이란?
싱글 페이지 애플리케이션 : 자바스크립트를 활용해 하나의 페이지에서만 렌더링 수행
서버 사이드 렌더링 : 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공
=> 웹 페이지 렌더링의 책임을 어디에 두느냐의 차이
- 서버 사이드 렌더링의 장점
-
최초 페이지 진입이 비교적 빠르다.
화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 서버 사이드 렌더링이 더 빠를 수 있다. -> 서버가 사용자를 감당하지 못하면 SPA보다 느릴 수 있음 -
검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
서버 사이드 렌더링은 검색 엔진 최적화에 유용하다.*검색 엔진이 사이트에서 필요한 정보를 가져가는 과정
- 검색 엔진 로봇이 페이지에 진입
- 페이지가 HTML 정보를 제공해 로봇이 HTML 다운
- 페이지 내부의 오픈 그래프(Open Graph)나 메타(meta) 태그 정보를 기반으로 페이지 검색 정보를 가져오고 검색 엔진에 저장=> 검색 엔진에 제공할 정보를 서버에서 가공해 HTML 응답으로 제공할 수 있으므로 검색 엔진에 최적화
-
누적 레이아웃 이동이 적다.
-
사용자의 디바이스 성능에 비교적 자유롭다.
-
보안에 좀 더 안전
인증 혹은 민감한 작업을 서버에서 수행하기 때문에 보안 위협을 피할 수 있음
- 단점
- 소스코드 작성 시 항상 서버를 고려해야함
- 적절한 서버가 구축돼 있어야 한다.
- 서비스 지연에 따른 문제
4.1.3 SPA와 SSR을 모두 알아야 하는 이유
- 현대의 서버 사이드 렌더링
요즘의 서버 사이드 렌더링은 최초 웹사이트 진입 시 서버 사이드 렌더링 방식으로 완성된 HTML을 제공받고, 이후 라우팅에서는 마치 SPA처럼 작동한다.
4.2 서버 사이드 렌더링을 위한 리액트 API 살펴보기
4.2.1 renderToString
인수로 넘겨받은 리액트 컴포넌트를 렌더링해 HTML 문자열로 반환하는 함수
4.2.2 renderToStaticMarkup
renderToString과 매우 유사한 함수
data-reactroot와 같은 추가적인 DOM 속성을 만들지 않는다는 차이점이 있음
리액트의 이벤트 리스너가 필요 없는 완전히 순수한 HTML을 만들 때만 사용(블로그 글이나 상품의 약관 정보 등)
4.2.3 renderToNodeStream
node.js 환경에 의존
Node.js의 ReadableStream이 결과물이다. ReadableStream은 utf-8로 인코딩된 바이트 스크림으로 영상과 같은 큰 데이터를 다룰 때 데이터를 청크로 분할해 조금씩 가져올 수 있다.
4.2.4 renderToStaticNodeStream
renderToNodeStream과 동일한 결과물이지만 순수 HTML 결과물이 필요할 때 사용하는 메서드
4.2.5 hydrate
renderToString과 renderToNodeStream으로 생성된 HTML 콘텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할
정적으로 생성된 HTML에 이벤트와 핸들러를 붙여 완전한 웹페이지 결과물을 만든다.
4.3 Next.js 톺아보기
서버 라우팅과 클라이언트 라우팅 차이
next/link는 Next.js에서 제공하는 라우팅 컴포넌트
a태그와 next/link 차이
a태그로 이동할 때: webpack, framework, main 등 페이지를 만드는 데 필요한 모든 리소스를 처음부터 다 가져옴
-> 서버에서 렌더링을 수행하고, 클라이언트에서 hydrate하는 과정에서 한 번 더 실행됨
next/link로 이동할 때: 서버 사이드 렌더링이 아닌, 클라이언트에서 필요한 자바스크립트만 불러온 뒤 라우팅하는 클라이언트 라우팅/렌더링 방식으로 작동
Data Fetching
Next.js에서 서버 사이드 렌더링 지원을 위한 데이터 불러오기 전략 중 하나
pages/의 폴더에 있는 라우팅이 되는 파일에서만 사용할 수 있음
예약어로 지정되어 반드시 정해진 함수명으로 export를 사용해 함수를 파일 외부로 보내야함
