[MGS 3기 - 38일차] SSR과 CSR, Next.js

박철연·2022년 6월 4일
0

MGS STFE 3기

목록 보기
35/35

두번째 React 추가 강의를 수강한 뒤 요약해보았습니다. 이번 글에서는 SSR과 CSR, 그리고 SPA의 개념에 대해 자세히 다루었습니다. 이를 바탕으로 Next.js 개발 환경에 대한 이해도 다시 복습했습니다.

SSR이란 무엇인가

SEO

먼저 SSR을 알아보기 전에 SEO의 개념을 간단하게 알아볼 필요가 있습니다.

SEO는 검색엔진최적화 (Search Engine Optimization, SEO)를 지칭하는 것으로, 검색 엔진으로부터 웹사이트나 웹페이지에 대한 웹사이트 트래픽의 품질과 양을 개선하는 과정입니다.

SEO는 검색 엔진에서 정보를 수집하는 시스템이 내 서비스를 좀 더 잘 찾을 수 있도록 하는 과정이라고 보면 되겠습니다.

특히 우리가 자주 사용하는 구글 같은 경우를 보면, google 검색엔진이 page title, link(a tag) 등을 서비스에 포함된 html으로부터 수집하여 사용자에게 보여주는 과정을 거칩니다.

SSR의 개념

지난 정리글에서 살펴본 적 있는데, SSR은 Server Side Rendering의 약자입니다.

이는 server에서 브라우저가 해석가능한 html을 사용자가 요청할 때마다 생성해서 응답하는 것입니다.

SSR의 장점

  1. SEO가 용이함
  2. rendering에 필요한 js 를 번들에서 제외하여 traffic을 줄임
    => 사용자의 네트워크나 기기사양이 좋지 않다면 속도적 이점 있음
  3. 종단간 network call 횟수를 줄일 수 있음
    => 사용자의 네트워크나 기기사양이 좋지 않다면 속도적 이점 있음

SSR의 단점(CSR과 비교했을 때)

서버의 부하가 커짐 (rendering을 서버에서 수행하므로) = 비용증가
=> 서버의 사양이 좋지 않다면 속도가 느려질 수 있음

Next.js의 도입

Next.js와 SSR

Next.js는 React 기반 프레임워크입니다.

단순히 React 기반의 프로젝트 구성을 용이하게 해주는 것 뿐만 아니라, SSR을 활용한 페이지 구현을 가능하게 해줍니다. (물론 SSR뿐만 아니라 CSR도 지원합니다.)

url에 direct 로 요청하면 pre-rendered된 html을 내려 받는 식으로 작동합니다.

추후 페이지 이동시 CSR을 활용한 SPA 구현을 하는 식입니다.

모든 페이지를 SSR로 구성할 수도 있지만, SPA의 장점을 살리기 위해 최초에 SSR로 페이지를 구성하고, CSR +SPA 식으로 추가 페이지를 로드하는 방식이 보편적입니다.

create-next-app

create-next-app도 이미 지난 정리글에서 다룬 적이 있습니다. 오늘은 실제 코드를 작성해보기 위해 프로젝트를 직접 만들어 보겠습니다.

저는 타입스크립트 기반으로 next.js 프로젝트를 만들었습니다.

다음과 같이 프로젝트가 구성되었다면 아무 문제없이 next 프로젝트가 잘 구축된 것입니다.

위 이미지의 script 부분에서 볼 수 있듯이 npm run dev 명령어로 개발 서버를 띄울 수 있습니다.

Routing on Next.js

보통 React 프로젝트에서는 라우팅을 위해 react-router-dom과 같은 라이브러리를 사용합니다.

하지만 Next.js는 프레임워크 답게 아주 간편한 라우팅 방식을 제공해줍니다.

Next.js의 라우팅 방식을 정적 라우팅과 동적 라우팅으로 구분해서 요약해보겠습니다.

정적 라우팅

정적 라우팅은 매우 간단합니다. 미리 만들어진 pages 폴더 안에 내가 라우팅하고자하는 url의 이름으로 파일을 작성해주면 됩니다.

실제로 create-next-app으로 만든 프로젝트를 보시면, pages 폴더 안에 api라는 폴더가 하나 더 있고, 그 안에 hello.tsx 파일이 있습니다.

따라서 현재 개발 서버의 url 뒤에 /api/hello를 한번 입력해 보면 다음과 같이 hello.tsx의 응답이 화면에 잘 출력됩니다.

동적 라우팅

동적 라우팅은 pages 폴더 내에 [파라미터명].js 식으로 작성하여 구현할 수 있습니다.

react-router의 parameter와 유사하다고 볼 수 있습니다.

예를 들어, pages/[id].js 를 작성하면 localhost:3000/a 에 접속하였을 때 해당 컴포넌트를 렌더하고 a라는 문자열을 parameter로 넘깁니다. ( { "id": "a" } )

useRouter

react-router에서 useParams를 사용하였듯이, useRouter().query를 통해 parameter를 가져올 수 있습니다.

대략적인 코드의 구조는 다음과 같을 것입니다.

파라미터 이름을 [id]로 지엇으니까, query 뒤에 id를 붙여주면 url이 바뀔 때마다 페이지의 내용도 바뀌게 될 것입니다.

만약 localhost:3000/post/abc에 접속한다면, router.query는 { "id": "abc" } 라고 출력되겠죠.

getServerSideProps

getServerSideProps는 SSR 구현을 위해 사용자 요청이 들어올 때마다 필요한 작업을 통해 HTML 구조를 짜주는 메서드입니다. (이름은 내장 함수이기 때문에 반드시 지켜줘야 합니다.)

위 코드를 보시면 getServerSideProps의 역할을 잘 파악할 수 있습니다.

현재 a.tsx 컴포넌트는 div 안에 props.name을 출력하도록 되어 있습니다.

그리고 getServerSideProps 함수를 만들어서 props의 내용을 return해줍니다. 지금은 props.name을 'asdf'로 했습니다.

따라서 화면에는 'asdf'가 출력될 것입니다. 다음과 같이요.

만약 props.name 안을 Math.random()과 같은 가변적인 값을 넣으면 렌더링할 때마다 새로운 내용을 출력할 것입니다.

getServerSideProps는 요청마다 바뀌는 화면일 때, 요청자에 따라 다른 화면을 출력하는 경우에 매우 효율적입니다.

profile
Frontend Developer

0개의 댓글