Server Side Rendering
- React, Vue, Angular 등 자바스크립트 프레임워크가 나오기 이전
초기 웹 환경에서는 모든 페이지를 서버에서 빌드 - 클라이언트는 별도의 처리 없이 웹페이지 노출
- 이를 server Rendering이라고 함
Client Side Rendering
- Ajax 등의 기술, 자바스크립트 프레임워크를 활용하여, 데이터를 받아 자바스크립트로 페이지를 동적으로 만들 수 있게 됨
- 데이터는 XML, JSON 형태로 클라이언트에 전송
- 이를 CSR(Client Side Rendering)이라고 함
CSR의 장점
- csr은 자바스크립트만으로 완전히 페이지를 만들 수 있음
- 자바스크립트를 최대한도로 활용하여 html, css를 동적으로 생성
- 컴포넌트 단위로 코드를 나누고, 다양한 디자인 패턴을 적용하는 등,
클라이언트 개발의 수준을 한단계 끌어올림 - Full page load 없이 라우팅
CSR의 단점
- 자바스크립트 코드가 많으면 앱 로딩이 느려짐
- SEO가 좋지 않음
Server side Rendering
- 서버에서 자바스크립트를 이용해 페이지를 미리 빌드
- 컴포넌트 생성에 필요한 api 요청, routing, redux store 생성 등을 처리
- 클라이언트는 빌드된 페이지와 자바스크립트를 받아,
웹앱을 CSR처럼 동작하게 함 - 이런 특징으로, universal rendering이라고도 함
웹 퍼포먼스
- 웹페이지가 로드되고 유저와 상호작용하는 모든 것들을 측정
- 성능을 측정하여 웹앱의 사용성을 개선할 수 있음
- 열악한 네트워크 환경에서도 사용 가능한 앱을 만드는 등
좋은 유저 경험으로 유저의 만족을 얻음
Time to First Byte
- 페이지 요청 후, 처음 데이터가 도착하기까지 걸리는 시간
- 요청을 받았을 때, 서버에서 처리하는 시간이 오래 걸리거나,
네트워크가 딜레이되는 등의 상황 발생 시 지표가 악화됨
First Contentful Paint
- 페이지에 진입하고부터, 브라우저가 어떤 DOM Content를 만들때까지 걸리는 시간
- 페이지 진입 후 FCP까지 평균 3초 이상 걸리면 성능 개선이 필요
Time to interactive
- 웹페이지 진입 후, 유저가 클릭, 스크릭, 인풋 등의 행위를 하기까지 걸리는 시간
- 자바스크립트가 로드되고 나서, 이벤트 핸들러 등이 부착되어
입력을 처리할 수 있기까지의 시간
SSR의 페이지 로드 방식
- 유저가 빠르게 페이지의 내용을 볼 수 있도록 html을 미리 빌드하여 FCP 등의 키 메트릭을 개선함
- 서버 자원을 활용하여, 초기 큰 성능이 필요한 페이지 등을 빌드하는데 활용
SSR의 장점
- Crawler는 페이지를 Indexing 하기 위해 페이지에 관한 많은 정보가 필요
- SSR을 활용하여 미리 페이지를 빌드하면, Crawler에게 많은 정보를 줄 수 있음
- SEO(Search Engine Optimization)에 유리
SSR의 단점
- CSRDP QLGO TTFB에 불리함
- 별도의 서버를 유지하는 비용
- Static rendering보다 CDN Caching에 불리
ReactDOMServer
- ReactDOMServer를 활용하여, 특정 React COmponent를 html로 빌드
- Node.js 서버에서 JSX를 사용하여 페이지 빌드
renderToString
- React Component를 html로 변환함
- 클라이언트의 페이지 요청 시, 변환된 html string을 전달
- renderToNodeStream은 readable stream을 생성
브라우저가 받아서 점진적으로 페이지를 그림
ReactDOM.hydrate
- renderToString으로 생성한 HTML의 root을 기준으로
받아온 React code를 통해 markup에 이벤트 핸들러를 등록하는 등
컴포넌트화.
Hydration 시 주의할 점
- 서버에서 생성한 컴포넌트와 브라우저에서 hydration을 거친 후의 마크업이 다르면, react runtime은 경고를 보냄
ex) 현재 시간을 보여주는 컴포넌트 - 경고 발생 시, 어느 부분에서 차이점이 생기는지 반드시 파악해야 함
- componentDidMount 역할을 하는 useEffect의 경우, SSR 시 서버에서 동작하지 않음
- data loading 등의 처리를 별도로 해주어야 할 필요가 있음
React 앱 배포 Overview
- 인터넷에서 내가 만든 앱에 접근할 수 있어야 함
- 지속적으로 앱을 수정하고 배포해야 함
- Public IP 주소로 직접 접근할 수 있도록 함
- IP를 부여 받은 서버에 react 앱을 배포
- 앱을 서빙하는 웹서버를 통해 사용자에게 앱을 전달
- 사용자는 IP를 통해 앱에 접근
react 앱 배포 프로세스
- IP를 부여받은 서버(VM)에 React 앱을 배포
- 앱을 빌드하고, 웹 서버를 세팅
- 앱을 서빙하는 웹서버를 통해 사용자에게 앱을 전달
- 사용자는 필요한 데이터를 받아 앱을 로딩
프론트엔드 앱 배포시 유의할 점
- 서버와 통신 시, CORS가 허용되었는지 점검
- 브라우저, 디바이스별로 앱이 정상적으로 동작하는지 점검
- 앱의 로딩 속도, 각 동작 시 성능, 버그 등을 점검
react 앱 준비
- yarn.lock, package-lock.json이 동시에 존재하지 않는지 점검
- 로컬에서 npm run build를 실행하여, 빌드 시 에러가 발생하지 않는지 점검
- 로컬에서 배포하여, production build가 제대로 실행되는지 점검
github 연동
git remote add origin https://gitlab.com/{gitlab_id}/{project_name}
git push --set-upstream origin master- 작성한 프로젝트 코드를 gitlab에 배포
- 프로젝트가 gitlab에 잘 올라갔는지 점검
- last commit까지 적용되었는지 점검
Azure를 사용한 VM 배포
- Azure 계정을 만듦
- portal.azure.com에 접속
- Virtual Machine을 검색해, Virtual machine 리소스 페이지에 접속
- Create > Virtual machine 버튼을 클릭
VM 설정
- Resource group은 필요하다면 새로 만들어 설정
- Virtual machine name을 설정
- Ubuntu Server 20.04 LTS 로 생성
- 그 외 세팅은 default로 유지
- SSH public key로 설정
- key pair는 다운받음
- 유저 이름은 azureuser로 유지
- 포트 접근은 모두 허용함
Azure를 사용한 VM 배포
- Review & Create 버튼을 눌러, 마지막으로 점검한 뒤에 생성
접근 테스트
- 다운받은 private key를 .ssh 밑으로 옮김
- ssh 커맨드로 VM 서버에 접근
> mv {private_key} ~/.ssh
> ssh -i ./{private_key} azureuser@{id_address}
# 나갈때는 exit- 다운 받은 private key를 .ssh 밑으로 옮긴다.
- ssh 커맨드로 VM 서버에 접근한다.
React 앱 배포를 위한 Azure VM 세팅
- VM 에서 nodejs, npm을 설치
- 앱을 빌드하는데 필요한 npm package를 설치
- serve를 이용해 앱을 배포
Node.js, NPM 설치
> sudo apt update
> sudo apt instatll nodejs
> sudo apt instatll npm- NPM, Node.js를 설치
프로젝트 패키지 설치
> git clone https://gitlab.com/{gitlab_id}/{project_name}
> cd {project_name}
> npm i- 프로젝트 코드를 git clone으로 다운
- npm i로, 빌드에 필요한 패키지를 설치
빌드 후 배포
> sudo npm i -g serve
> npm run build
> sudo -s -p 80 build- 프로젝트를 빌드
- serve 웹서버를 사용해 프로젝트를 80번 포트에서 서빙
나를 위한 업그레이드 아자아자