Next.js의 특징(왜 Next.js를 쓰나, 서버사이드렌더링, 서버사이드렌더링 원리, 서버액션, 서버리스함수, API Route, hydrate)

짧은 지식으로 인해 글의 신뢰성이 높지 않습니다. 정확한 내용은 공식문서를 참고해주세요.

 

몇달 전 부트캠프에서 백엔드 코드 없이 웹앱을 만들 수 있는지 궁금했었다.
그때 알게 된 두가지 방법이 firebase(or supabase)를 이용하는 방법과 넥스트제이에스로 구현하는 방법이었다.

그때는 참 미지의 세계처럼 느껴졌는데 next.js를 공부할 일이 생겨 지난 일주일간 next에 대해 공부하고 보니 어렴풋이 next.js의 특징을 알게 되었다. 그때의 나에게 넥스트제이에스를 설명한다면 이렇게 설명해주고 싶다.

 

목차)

1. 왜 Next.js를 쓰나

2. Next.js의 장점, 특징(서버사이드렌더링 말고 무슨 장점이 있나)

  2-1. 서버사이드 렌더링

  2-2. serverless function(서버 액션과 API route)

 

1. 왜 Next.js를 쓰나

 

Next.js는 리액트의 프레임워크이다.
리액트는 routing, testing, error handling 등의 기능을 지원하지 않는다.

그래서 직접 여러 라이브러리를 가져와서 기능을 만들어야 한다.

예를 들면 라우팅은 react-router-dom을 쓰고 test는 vitest 에러는 직접 error boundary를 구현하는 식이다.

next는 간편하게 여러 기능을 제공한다.

app routing, error page, loading page, server components 뿐만 아니라 streaming, paralell route 등 여러 특징이 있다.

next에서 제공하는 기능은 angular나 다른 프레임워크에서도 제공하는 기능도 많지만 리액트를 쓴다면 next는 좋은 프레임워크라고 생각한다.
리액트 공식 문서에서도 routing과 data fetching등 의 기능이 있는 프레임워크를 쓸것을 권장하고 있다.

https://react.dev/

 

2. Next.js의 장점 (서버사이드 렌더링 말고도 장점이 있나?)

 

2-1 서버사이드 렌더링(SSR vs CSR)

서버 사이드 렌더링과 클라이언트 사이드 렌더링의 차이는 이름에서 보다싶이 어디서 렌더링 되느냐이다.

 

리액트(CSR)의 작동 방식은 아래와 같다
1. 초기 HTML 로드: 주로 비어있는 root <div>를 로드
2. JS 파일 다운로드 및 실행: 브라우저에서 JS파일을 다운로드, 파싱, 실행
3. 리액트 컴포넌트 렌더링: 리액트는 root <div> 의 컴포넌트를 렌더링
4. DOM 업데이트 및 인터랙티브 웹: 가상 DOM과 실제 DOM의 차이를 비교하여 DOM 업데이트, JS로직 attach한 interactive한 웹  

즉 브라우저는 당장 필요하지 않은 자바스크립트 파일도 다운로드, 파싱 작업을 해야하고

Initial Page Load와 First Contentful Paint 시간은 당연히 SSR에 비해 느리다.

반면 next.js의 서버사이드 렌더링이다. 
넥스트는 모든 컴포넌트를 서버에서 렌더링 한다(클라이언트 컴포넌트도 일차적으로 서버에서 렌더링한다)

서버사이드 렌더링의 장점을 살펴보기 전,

서버 컴포넌트가 렌더링되는 SSR원리를 살펴보자

 

먼저 route경로과 suspense boundary에 따라 chunk로 나누어져서 렌더링 작업이 이루어지고.
서버 측과 클라이언트 측으로 나누어 진다.

 

서버 측:

1. 리액트가 서버 컴포넌트를 React Server Component Payload (RSC Payload)로 렌더링, 클라이언트로 전달
2. RSC Paload(서버컴포넌트의 HTML + 데이터 포함) 를 참고해서 서버컴포넌트의 HTML을 서버에서 렌더, 클라이언트 컴포넌트의 HTML도 서버에서 렌더

클라이언트 측:

1. 서버에서 전달받은 HTML로 non-interactive 페이지 로드 (빠른 Initial Page Load)
2. RSC Payload를 기반으로 서버컴포넌트 트리와 클라이언트 컴포넌트 트리의 동기화.
   클라이언트는 서버에서 전달된 데이터로 현재 상태와 비교해 필요한 경우 DOM update ( Reconciliation )
   이 동기화 과정에서 첫 번째 콘텐츠가 화면에 나타나는 시점이 First Contentful Paint(FCP)
3. Hydratation: nextjs의 hydration은 서버에서 렌더된 HTML을 interactive하게 만드는 과정으로, 
   간단히 말하면 컴포넌트의 로직(javascript)를 attach하는것. event listener 등 attach해서 유저와 상호작용이 가능한 인터렉티브 웹앱이 됨.

이렇게 서버에서 HTML을 렌더해서 빠르게 화면과 콘텐츠를 로드.
뿐만 아니라 다양한 서버사이드 렌더링의 장점이 있다.

 

SSR의 장점:

1. Data Fetching:
   • 서버 컴포넌트에서 데이터 fetching을 해서 클라이언트측에 data fetching과정은 감추고, 정제한 data를 RSC로 변환해서 서버에서 렌더링 가능
   • 데이터가 서버랑 클라이언트를 왔다갔다 하는 시간도 사라짐
2. Security:
   • 민감한 데이터나 비즈니스 로직을 서버에서 처리하여 클라이언트에 노출하지 않음. 보안에 유리
3. Caching:
   • 서버 측에서는 데이터를 가져오는 fetch의 반환 값을 기본적으로 캐싱, 다양한 캐싱 전략 적용가능
   • 데이터 요청 횟수 감소
4. Performance:
   • non-interactive 코드 (리액트 훅을 사용하지 않거나 유저와 상호작용 하지 않는 코드는) 서버 컴포넌트로 옮기면 브라우저에서 불필요한 자바스크립트 파일의 다운로드, 파싱, 실행 감소. -> 빠름
   • 클라이언트 측의 부담을 줄여 성능을 향상
5. Initial Page Load 및 First Contentful Paint:
   • 서버에서 HTML을 미리 렌더링하여 클라이언트에 전달하므로, 초기 페이지 로드와 FCP 시간 단축
6. Search Engine Optimization (SEO) 및 Social Network Searchability:
   • 서버에서 렌더링된 HTML은 검색 엔진 크롤러와 소셜 네트워크 봇이 쉽게 접근
   • SEO 최적화 , 소셜 네트워크에서의 콘텐츠 공유 시 메타데이터와 함께 표시
7. Streaming:
   • 서버에서 렌더링된 HTML을 청크로 나눠서 스트리밍(suspense, routing segment 단위)
   • 전체 페이지 로딩 기다릴 필요 없음

이라는 장점이 있다고 문서에서 설명하고 있다
https://nextjs.org/docs

Docs | Next.js

 

 

 2-2. serverless function(서버 액션과 API route)

 

그러면 만약에 내가 만들고자 하는 웹앱이 속도도 크게 중요하지 않고, 비즈니스 로직도 감출 필요가 없다면
그래도 next.js를 쓰는게 의미가 있을까?

next는 빠르고(위의 장점에 나온 streaming, server rendering, caching, performance) 보안에 유리(server componet로 민감한 데이터나 중요 비즈니스 로직은 서버에서 실행 가능)하지만 그 뿐만이 아니다.
편리하다 

간단하게는 로딩페이지와 에러페이지, 레이아웃 처리부터

더 나아가 serverless function을 활용 할 수 있다.

 

서버리스 함수란, 서버를 따로 관리 하지 않고 서버 로직을 실행할 수 있는 환경을 제공하는 것 이다.

프론트엔드의 프레임워크 선택에 있어 서버리스 함수와 큰 커뮤니티, 안정적인 infrastructure, 배포 수단은 중요한 고려사항이다. 라고 들었다.

넥스트의 서버리스 함수는 AWS Lambda, Vercel Serverless Functions, Google Cloud Functions 등 다양한 서버리스 플랫폼에서 동작한다.

 

크게 두가지로 나누어지는데 서버액션과 API Route이다

서버측 코드를 실행시킬 때 서버액션을 쓰는게 좋은지 API Route를 쓰는게 좋은지는 아직도 논쟁거리 인듯 하다.
나는 form 제출등에는 서버액션을 data fetch에는 API Route를 활용할 계획이다.

 

API Route로 직접 API 엔드포인트를 만들어서 이를 클라이언트 컴포넌트에서 호출하는 방법.

서버컴포넌트에 서버액션을 정의하고, 클라이언트에서 특정 이벤트(폼 제출 등)에 따라 서버의 함수를 실행시키는 방법.

등이 있다.

 

그리고 서버리스 플랫폼을 활용하지 않아도 간단하게 서버로직과 프론트 로직을 next.js라는 같은 코드베이스에서 간단하게 구현 가능한 점이 next.js의 큰 장점 이라고 생각한다.

글을 마무리하면서

next.js를 배우며 들은 조언을 첨부한다.

"클라이언트 컴포넌트로 남겨야 할 부분만 클라이언트 컴포넌트로 남겨라.
특정 컴포넌트에 interactive로직이 들어간다고
컴포넌트를 통째로 client component로 만들 필요는 없다."
https://frontendmasters.com/courses/next-js-v3/

Introduction to Next.js 13 & App Router | Fullstack Web App Framework Course