리액트만 사용할 때와 비교해 Next.js를 사용하는 이유와 SSR 실행과정

 

리액트만 사용할 때와 비교해 Next.js를 사용하는 이유에 대해 설명해 주세요.

Framework vs Library

React는 라이브러리이고, Next는 React의 프레임워크이기 때문에

우선 프레임워크와 라이브러리의 차이점을 짚고 넘어가자면,

프레임워크

• 개발자가 소프트웨어 기능 구현에 개발할 수 있도록 코드를 구현해 개발 시간을 줄이고,  코드의 재사용성을  증가 시키기 위한 일련의 뼈대, 틀을 라이브러리 형태로 제공되는 것

라이브러리

• 특정 기능을 모아둔 코드 혹은 함수들의 집합이며 코드 작성 시 활용 가능한 도구들

큰 차이점은 "애플리케이션의 흐름을 누가 쥐고 있느냐"

• 프레임워크는 그 스스로 제어 흐름의 주도성을 갖는 반면, 라이브러리는 개발자가 가지고 있다.
• 프레임워크는 집이고, 라이브러리는 그 집 안의 가구 (프레임 워크는 전체적인 tool 을 제공 , 라이브러리는 하나의 기능만을 도구처럼 제공 )
• 라이브러리와 달리 프레임워크는 설정파일의 태그설정이나, DB연동 방법등 이미 프로그래밍에 대한 규칙을 가지고 있기 때문에 개발자는 이를 따라야한다.

 

 

우선 Next.js를 사용하는 가장 큰 이유는 바로 SSR이다

초기 로딩 속도가 빠른 SSR, 페이지 전환이 빠른 CSR

SSR은 서버에서 View를 렌더링 하기 때문에 초기 로딩 속도가 빠르고 검색 엔진 최적화 (SEO)에 유리하다.
CSR은 서버가 아닌 클라이언트 측에서 서비스에 필요한 자원을 먼저 다운로드 후에 브라우저에 렌더링 하는 방식이다.  초기 로딩 속도가 비교적 뒤쳐지지만, 첫 페이지를 로딩하면서 모든 파일을 다운로드하기 때문에 페이지를 이동할 때마다 해당 페이지에서 필요한 데이터만 불러서 사용한다.

간단한 차이는 유저가 브라우저에서 보는 화면인 UI를 어디서 만들어 주는지에 따라 구분된다.

 

React는 ui를 만드는 기능만을 제공하기에 라이브러리!

리액트는 CSR(Client Side Rendering)로 렌더링이 클라이언트에서 발생하기에

서버에서 보내주는 HTML과 Javascript 파일을 서버가 아닌 클라이언트의 브라우저에서 페이지를 만들어준다.

이러한 방식은 페이지 간 전환이 부드러워지는 장점이 있다.

 

Reat의 단점 ..

HTML과 JS를 다운로드 받는동안 클라이언트는 렌더링이 불가능하여 첫 페이지의 로딩속도가 느리다는 단점이 있다.

또한 CSR의 특성상 빈 HTML과 JS를 보낸 뒤 클라이언트의 브라우저에서 JS를 실행시켜 화면을 그리는데, 대부분의 검색 엔진은 HTML 파일만 크롤링합니다. Meta 태그 또한 크롤링 봇이 가져가지 못하기에, meta 태그를 이용하는 마케팅 툴또한 사용할 수 없다. 이러한 점들은 SEO(Search Engine Optimization)에 악영향을 끼쳐 구글과 같은 검색 사이트의 상위 노출에 불리해지기에 웹 비즈니스에 있어 매우 큰 단점으로 작용한다.

크롤링 : 웹페이지의 정보를 자동으로 수집, 준류 저장하는 것

 

 

Next.js를 사용하는 이유

이러한 단점들을 극복하기 위해 최근 들어 React Meta-Framework들이 나왔는데

대표적으로 Gatsby, Next.js, Remix 등이 있고, 그중에서도 Next.js가 있는 것이다.

Next.js 는 2022년 10월 Next.js 13 version이 나오면서 많은 것들이 바뀌며 사용률, 만족도가 압도적으로 높아졌다.

웹 프레임워크의 특성상 해당 프레임워크 커뮤니티의 크기가 중요하기에, 아직 인지도가 적은 타 프레임워크들보다는 만족도가 높고 활발한 커뮤니티를 가진 Next.js가 가장 유용한 편!

 

SSR을 쉽게 구현하도록 도와주는 프레임워크

Next.js는 React의 SSR(Server Side Rendering)을 쉽게 구현할 수 있게 도와주는 프레임워크다.

물론 React에서도 SSR이 구현 가능하지만, React로 구현하는 것은 굉장히 복잡한 일이기 때문에 Next.js가 등장했다.

 

추가적인 장점

automatic routing

기존에 CRA(Create-React-App)로 개발했을 때는 index.js만 불러와서 SPA (Single Page Application)방식으로 라우팅에 따라 컴포넌트를 교체하는데,

Next.js로 개발하게 되면 pages 디렉토리에 있는 파일을 기준으로 라우터별로 다른 페이지로 넘어가게 된다.

또한 Next.js에서 지원해 주는 Head 등을 통해 메타 태그를 입력해 주면 SEO에 문제가 없다.

(이것은 최근에 Next에서 제공하는 App Router 방식도 도입이 되긴함)

 

Next.js는 자동으로 코드 스플리팅(분할)을 한다.

보통 개발을 할 때, 속도가 느리거나 혹은 메모리가 낮은 기기를 활용할 때 여러 가지 불편함이 발생할 수도 있는데,

이런 문제를 사전에 방지하고자 JS 프로젝트를 생성할 때, 모든 코드를 하나의 Bundle(묶음)으로 만든다.

이러한 과정을 번들링이라 한는데 이러한 과정은 간단한 프로젝트를 개발하면 괜찮지만 프로젝트 규모가 커지면 전달해야 하는 파일도 커지고 브라우저가 파싱해야 하는 정보도 많아지기 때문에 앱 초기 구동 속도가 느려진다.

 

리액트에서는 이런 번들이 거대해지는 것을 방지하기 위해 여러 번들을 동적으로 생성하고 불러오는 코드 스플리팅(분할)을 지원한다. 이런 코드 분할은 Lazy Loading (지연 로딩)을 할 수 있게 도와주고, 코드 양을 줄이지 않고도 필요하지 않은 코드를 불러오지 않게 하여 초기 로딩에 필요한 자원을 줄여준다. 정리하면, 번들링된 파일을 분할해서 로드하여 초기 구동 속도를 빠르게 하고 성능 향상을 제공한다.

 

Next.js에서 SSR을 실행하는 과정과 hydration에 대해 설명해 주세요.

유저와 서버, 브라우저 각각의 입장을 나눠서 생각!

React의 동작 방식(CSR)

1. 유저가 브라우저를 통해 앱에 접속
2. 앱은 브라우저에게 자바스크립트 정보가 들어있는 빈 HTML 문서를 전달 (즉, 브라우저에게 자바스크립트 파일을 전달)
3. 브라우저는 자바스크립트 파일을 다운로드하고 동시에 유저는 빈 화면을 보게 됨
4. 브라우저에서 js 파일의 다운로드가 끝나면 리액트 코드가 있는 js 파일을 실행
5. 브라우저에 있는 리액트 코드가 UI를 렌더링한다 (동적으로 렌더링)
6. 유저는 앱이 보여주고자 했던 화면을 보게 된다

브라우저가 자바스크립트 코드를 가지고 있지 않거나, 요청 중인 상태라면 UI를 구성할 수 없고, 유저는 빈 화면을 보게 된다. 리액트 코드가 실행되기 전까지는 유저 화면에 아무것도 보이지 않는다. 이러한 클라이언트 측에서 UI를 빌드하는게 CSR방식이다.

 

Next의 동작 방식(SSR)

1. 유저가 브라우저를 통해 앱에 접속
2. 서버에서 리액트를 실행
3. 리액트는 UI를 렌더링
4. 렌더링된 결과를 통해 브라우저에게 HTML을 제공한다 이때 유저는 앱의 초기화면을 보게 됨 (접속에 대한 응답)
5. 이후 브라우저는 리액트 코드가 있는 자바스크립트 파일을 다운받고 실행시킨다. 즉, 서버에서 UI를 모두 구성한 후 유저에게 응답해 화면을 보여주는 방식으로, 화면이 pre-rendering되어 유저는 인터넷 속도에 상관없이 화면에 뭔가 나오는 것을 볼 수 있다. 이러한 서버 측에서 UI를 렌더링하는 것이 SSR 방식이다.
6. 사용자는 SSR을 통해 UI를 미리 보고, Hydration을 통해 페이지 조작이 가능하다!

 

hydration : Server-Side에서 렌더링 된 정적 페이지(HTML)와 번들링 된 JS 파일을 클라이언트에게 보내면, Client-Side에서 HTML 코드와 JS(React) 코드를 서로 매칭시키는 과정

Hydration 은 수분 공급이라는 의미를 갖는다. JS 코드들이 DOM 요소 위에 물을 채우듯 필요로 하던 요소들을 채운다하여 붙여진 이름이라고 한다.