SSR
(Server Side Rendering) 웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링한다. 사용자가 브라우저의 다른 경로로 이동할 때마다 서버에서는 렌더링 작업을 반복한다.
-> 동적 웹사이트: 서버에 의해 HTML 파일이 동적으로 생성되는 사이트 (SSR)CSR
(Client Side Rendering) SSR이 서버 측에서 페이지를 렌더링한다면, CSR은 클라이언트에서 페이지를 렌더링한다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지의 골격이 될 html(단일 페이지)와 JavaScript 파일을 클라이언트에 보낸다. 클라이언트가 파일을 받으면 사용자의 액션에 따라 JavaScript 파일이 동적으로 렌더링 된다.
-> 정적 웹사이트: HTML 파일(코드) 자체로 배포되는 사이트 (CSR)차이점
CSR과 SSR의 주요 차이점은 페이지가 렌더링되는 위치로, SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링한다. 브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리한다.
사용
SSR은 완성된 html을 받아오므로 주로 SEO가 우선순위인 곳에서 사용한다. 또한 웹페이지의 첫 화면 렌더링이 빠르게 필요하고 사용자와 상호작용이 적은 경우 사용한다. 예를 들어, 네이버 블로그, 뉴욕 타임즈 웹페이지가 있다. CSR은 풍부한 상호작용과 더 나은 사용자경험이 필요한 경우 사용한다. 아고다를 비롯한 다양한 예약 사이트에서 사용하고 있다.
yes! 🙌
현대의 웹 앱은 정적 웹페이지와 AJAX 기술을 함께 사용하며, SPA(Single Page Application)으로 변모함에 따라 클라이언트의 규모가 커지게 되었다. 이 때 웹사이트 구성요소를 각 파일로 분리하는 모듈화가 이뤄지게 되며, React와 같은 클라이언트 기술이 발전하면서, 단일 파일로 자바스크립트나 페이지를 만드는 작업은 보다 고도화되기 시작했다.
고도화된 클라이언트 웹 앱은 수많은 모듈로 이뤄져 있다. 수많은 모듈을 하나로 묶어주는 작업을 번들링(bundling)이라고 하며, 이 과정에서 JSX 파일과 같이 브라우저에서 자체적으로 해석이 불가능한 다양한 보조 기술들을 브라우저가 해석할 수 있도록 만들어주는 작업 과정을 "소프트웨어 빌드"라고 부른다.
즉, "소프트웨어 빌드"는, 소스코드를 실행 가능한 결과물로 변환하는 작업을 의미한다.
다양한 모듈은 정적 파일들로 결과가 만들어져야만 하며, 따라서 이러한 빌드 과정은 배포에 필수적이다.
예를 들어, 우리가 여태 만들어 왔던 방식 Create React App 등으로 생성한 React 프로젝트의 경우에는, npm build 명령어가 package.json 파일에 포함되어 있으며, 이 명령어는 모듈을 정적인 파일로 만들어주게 된다. 이러한 프로젝트를 인터넷 상에 배포하기 위해서는 이렇게 만들어진 정적 파일을 호스팅하는 서비스에 결과물만 업로드하면 된다! 😆👌
React 프로젝트 생성 툴
- Create React App : react-scripts 모듈
- Next.js : next 모듈
빌드 툴
- webpack: 모듈 번들러
- babel: TypeScript, JSX 등과 같이 브라우저가 지원하지 않는 언어를 JavaScript로 바꿔주는 컴파일러
- ESLint: 자바스크립트 Code convention 및 문법 검사기
- Sass, less: CSS Preprocessor
로컬 환경에서 개발한 코드를 실제 서비스로 만들기 위해서는, 빌드 과정과 이를 웹에 노출시키는 배포 과정을 필요로 하다. 빌드를 통해 만든 정적 파일이 웹을 통해 제공(serve)되려면, 이러한 정적 파일을 제공하는 웹 서버(호스팅 서비스)가 필요하다. 아래는 다양한 웹 호스팅 서비스이다.
- Amazon Web Service (AWS) S3
- Google Cloud Storage
- Vercel
- GitHub Pages
- Netlify
- Heroku
🧐
Vercel-Github을 이용한 클라이언트 배포