Next.js, 개념에 대해 자세히 알아보자!

📌Next.js란?

웹 어플리케이션을 구축하기 위한 React 프레임워크

👇 그래서.. React랑 뭐가 다른건데!!
👇 React와의 차이를 알아보기 위해 CSR과 SSR에 대해 짚고 넘어가보자!

📌CSR vs SSR

✅ CSR (Client Side Rendering)

• 클라이언트 쪽에서 렌더링을 진행하는 방식이다.
• 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내주고 클라이언트에서는 이것을 받아서 렌더링을 시작한다.
• 서버에서의 처리없이 클라이언트로 보내주기 때문에, 모든 JavaScript 파일을 다운로드하는 동안 제대로 된 화면을 볼 수 없다.
• 브라우저가 JS를 다운로드하고 동적 DOM을 생성하기 위해 초기 로드 시간이 오래 걸린다.
• 이후 렌더링은 서버에서 해당 데이터만 response 받아 사용하면 되기 대문에 첫 렌더링 이후 구동 속도는 빠른 편이다.
• 검색 엔진 최적화(SEO)가 필요없거나, 데이터의 사전 렌더링이 필요없거나, 페이지의 내용이 실시간으로 자주 업데이트되어야 할 경우에는 유용하게 쓰이는 방식이다.

✅ SSR (Server Side Rendering)

• 서버 쪽에서 렌더링 준비를 마친 상태로 클라이언트에 전달하는 방식이다.
• 이미 렌더 가능한 상태로 서버에서 클라이언트로 전달되기 때문에, JavaScript 파일이 다운로드 되는 동안 사용자는 로딩 화면만 보고 있지 않아도 된다.
• 검색 엔진은 자동화된 로봇인 '크롤러'로 웹 사이트를 읽게 되는데,서버에서 렌더링된 HTML 파일을 보내주는 SSR은 검색 엔진 최적화(SEO)에 유리하다.
• JavaScript 파일 다운로드를 기다리지 않아도 되기 때문에 초기 구동 속도가 빠르다.
• 그러나 서버 호출 시 페이지가 새로고침 되며 깜빡임이 발생하고, 요청이 생길 때마다 서버에서 렌더링되지 않아도 될 부분까지 준비하기 때문에 서버 부하를 일으키기도 한다.

📌React와 Next.js

React와 Next.js의 가장 큰 차이점 중 하나는 렌더링하는 방식에 있다.
React는 CSR, Next.js는 SSR 방식으로 렌더링한다.

✅ React (feat. CSR)

• 대표적인 CSR 라이브러리인 React는 웹 사이트를 요청했을 때 빈 HTML을 가져와서 JS를 로딩하는 구조이다.
• 로딩 시간이 SSR에 비해 오래 걸리고, 만약 JS를 다룰 줄 모르는 검색 엔진이 사이트를 크롤링한다면 텅 빈 HTML만 인식하게 된다.
• 즉, CSR 방식을 사용하는 React는 로딩 시간도 비교적 오래걸리고 SEO에 취약하다는 단점이 있다.

✅ Next.js (feat. SSR)

반면, Next.js는 웹에 사이트를 요청했을 때 서버 측 렌더링을 거친 후 HTML과 JS를 따로 reponse한다.

💡 Next.js의 작동원리는 다음과 같다.

1. 초기에 사용자가 서버에 접속을 요청하면, SSR 방식으로 렌더링될 HTML을 보낸다.
2. 브라우저에서 JavaScript를 다운로드하고 React를 실행한다.
3. 사용자와 페이지가 서로 상호작용하며 다른 페이지로 이동하게 될 경우에는 CSR 방식으로 브라우저에서 처리한다.

• Next.js는 모든 페이지를 pre-render(HTML을 JS 처리하기 전, 사전에 생성) 하기 때문에, 검색엔진 최적화가 가능해진다.
• 사전 렌더링에 의해 만들어진 HTML은 해당 페이지에서 필요한 최소한의 JavaScript 코드와 연결된다.
• 어떤 페이지의 HTML이 브라우저에 의해 로드되면 그 HTML에 연결된 JavaScript 코드가 실행되어 해당 페이지 상호작용이 가능해지며, 이런 과정을 Hydration이라고 부른다.
• 즉, Next.js는 리액트 문법을 쓰는 프론트 문법을 쓸 수 있게 도와주 백엔드 프레임워크 라고 할 수 있다.

📌Next.js, 어떤 특징/ 기능을 가지고 있을까?

다음은 공식 문서에서 가져온 Next.js 특징 중 일부이다.

- 직관적인 페이지 기반 라우팅 시스템
- 사전 렌더링, 정적 생성(SSG) 및 서버 측 렌더링(SSR)은 페이지 별로 지원
- 더 빠른 페이지 로드를 위한 자동 코드 분할
- 최적화된 프리패치를 사용한 클라이언트 측 라우팅(CSR)
- 내장 CSS 및 Sass 지원 및 모든 CSS-in-JS 라이브러리 지원

👇 좀 더 자세히 알아보자!

1. Automatic Routing

React와 달리, 별도의 세팅없이 페이지를 기반으로 한 라우팅을 지원한다. React에서는 별도의 라우터를 제공하지 않기 때문에, react-router-dom이라는 패키지를 설치하여 사용했다.

Next.js 13은 app 폴더 하위에page 파일을 추가하고 그 안에 레이아웃을 넣는 방식으로, 추가한 파일을 export하게 되면 폴더명이 페이지 route가 되어 해당 파일이 라우터 역할을 하게 된다!

ex1. app/blog/page.js → /blog

ex2. app/blog/first-blog/page.js → /blog/first-blog

2. Dynamic Routes

항상 미리 정의된 경로를 사용할 수 있는 것은 아니다. 예를 들어 블로그 게시물의 경로는 /blog1, /blog2, /blog3 … 과 같은데, 모든 경로를 미리 정의하거나 페이지 컴포넌트를 생성하는 일은 굉장히 비효율적이다.

이때 사용하는 것이 동적 라우팅이다. [folderName]과 같이 폴더 이름을 대괄호로 묶어주면 해당 페이지 컴포넌트가 동적으로 라우팅 된다.

클라이언트 사이드에서 동적 경로에 접근하고 싶다면 next/link를 사용해주면 되고, router.push 같은 메소드를 사용할 수 도 있다!

📍 [folderName]

app/category/[slug]/page.js

Next.js 13 Automatic Routing에 따라 app 폴더 하위에 category 폴더를 만들고, 그 안에 Dynamic Routes를 위한 [slug] 폴더를 만든 것이다.
/category/food, /category/study 등의 주소는 모두 /post/[pid].js로 매칭된다.
[id]나 [slug]처럼 동적인 부분은 Layout과 Page나 Head 컴포넌트들에게 params prop으로 전달된다.

/category/food → { slug: 'food' }

/category/study → { slug: 'study' }

📍 Catch-all Segment : [...folderName]

app/shop/[...slug]/page.js

[slug]에 ...을 추가하여 shop 하위의 모든 경로를 잡아낼 수 있다.

/shop/clothes → { slug: ['clothes'] }

/shop/clothes/pants → { slug: ['clothes', 'pants'] }

/shop/clothes/tops/t-shirts → { slug: ['clothes', 'tops', 't-shirts'] }

3. Code Splitting

코드 분할은 다른 페이지에 대한 코드는 처음에 제공하지 않고, 원하는 페이지에 접근하는데 필요한 chunk(작은 코드 조각)만을 로드한다.

여러 개의 페이지가 있는 웹 사이트일지라도 필요한 페이지만을 빠르게 로드할 수 있으며, 이는 JavaScript 페이로드를 최소화하고 애플리케이션 로드 시간을 개선할 수 있다.

초기 페이지 로드에 필요하지 않은 구성 요소가 있는 경우 다음(👇)과 같이 동적으로 가져올 수 있다. 이는 필요할 때만 Puppy를 로드하도록 지시하고 있다.

// import Puppy from "../components/Puppy";
import dynamic from "next/dynamic";

// ...

const Puppy = dynamic(import("../components/Puppy"));

4. Client-Side Navigation

<Link /> 컴포넌트를 통한 페이지 이동이 빠르고 매끄럽다. HTML의 a 태그와 달리, 페이지를 리로딩하지 않는다. <Link />가 뷰포트에 보이면 관련 페이지를 백그라운드에서 미리 가져오기 때문에, 사용자가 링크를 클릭했을 때 매우 빠르게 해당 페이지로 이동할 수 있게 해준다.

5. TypeScript

TypeScript를 활용하기 위해서 웹팩이나 바벨을 만지지 않아도 된다. TypeScript를 설치하고 yarn run dev를 해주면 자동으로 tsconfig, next-end.d.ts가 생성되어 TypeScript를 사용할 수 있다.

yarn add typescript @types/node @types/react

yarn run dev

6. SSR + CSR

초기 페이지 로딩에서는 SSR 방식을 이용하여 처리하고, 이후의 요청에 대해서는 CSR 방식으로 처리하기 때문에 SSR 방식의 장점(SEO에 유리)과 CSR의 이점을 모두 활용할 수 있다.

7. Pre-rendering

Next.js는 모든 페이지를 사전 렌더링한다.

📌Next.js 13

👉 app/ Directory

• 기존 버전에서는 Automatic Routing 사용 시, pages 안에 파일 생성하여 별도의 라우터 없이도 애플리케이션 내부에서 즉시 경로 생성이 가능했다. 하지만 Next.js 13 버전부터는 app/ 디렉토리가 등장하여 라우팅 및 레이아웃 기능을 개선했다.
• 현재는 pages 디렉토리와 app 디렉토리가 공존할 수 있는 베타 버전으로 제공되고 있다.

👉 Streaming

• app/ 디렉토리에서 loading.js 예약 파일을 생성하면 렌더링이 되기 전에 로딩 중인 화면을 표시할 수 있는 기능이 추가됐다.
• 아래 코드처럼 엄청 간단하게 만들어볼 수 있다!

export default function Loading() {
	return(
		<div>Loading...</div>
	)
}

👉 Data Fetching

• 기존 버전에서는 데이터를 가져올 때 getServerSideProps()나 getStaticProps()를 사용했지만, Next.js 13 버전부터는 이 문법들을 사용하지 않는다.

• 공식문서에 따르면, 현재 Client Component에서의use() 사용은 권장되지 않으며, 이는 무수한 리렌더를 유발할 것이라고 언급하고 있다. Client Component에서 fetch 데이터가 필요하다면, SWR과 React Query와 같은 라이브러리 사용을 추천한다고 한다.

• 정적 데이터 가져오기

fetch('https://...'); // cache: 'force-cache' is the default

• 캐시된 데이터의 유효성을 주기적으로 다시 검사하려면 next.revalidate 옵션을 사용해서 리소스의 캐시 유효시간(초)을 설정할 수 있다.

fetch('https://...', { next: { revalidate: 10 } });

• 동적 데이터 가져오기

fetch('https://...', { cache: 'no-store' });

• fetch 구문의 URL 뒤에 { cache: '' } 를 넣어줄 수 있다. cache에 들어가는 내용에 따라 기존의 getServerSideProps(), getStaticProps()의 기능을 구현할 수 있다.

// Similar to `getStaticProps`.
fetch(URL, { cache: 'force-cache' });

// Similar to `getServerSideProps`.
fetch(URL, { cache: 'no-store' });

// Similar to `getStaticProps` with the `revalidate` option.
fetch(URL, { next: { revalidate: 10 } });

👉 etc..

이 외에도 Next.js 13에서 변경된 부분이 다수 있다. 자세한 내용은 nextjs.org를 참고해보자!

📘참고자료
How Next.js Works
What is Next.js?
Next.js를 사용하면서 리액트랑 별반 다르지 않다고 느꼈던 이유
[Next.js] 기본 개념 : Next.js 란? Next.js를 왜 사용할까? Next.js의 장점은?
Next.js 13
Next.js 13 신버전 발표회 요약
Next.js의 Routing
Next.js Dynamic Import(동적 가져오기): 성능 및 사용자 경험 개선
dynamic-routes