Next.js란?

💡 Next.js는 풀스택 웹 어플리케이션을 구축하기 위한 React.js 프레임워크이며 사용자 인터페이스를
구축하기위해 React를 사용하며 추가기능과 최적화를 위해 Next.js를 사용한다.
Next.js는 React에 필요한 번들링,컴파일 등과 같은 툴의 구성을 추상화하며 자동으로 설정해준다.
또한 Next.js는 리액트에서 제공해주지않는 SSR,SSG,ISR과 같은 다양한 렌더링 방식을 제공해준다.

Next.js의 주요 특징

1. Routing

NextJS에서는 App Router와 Pages Router방식의 두가지 라우팅 방식을 제공하며 react-router-dom을 설치할 필요 없이, route나 페이지구조를 정의하는데 javascript코드를 전혀 사용하지 않으며 특정한 폴더에 일반적인 react컴포넌트 파일을 생성하고 설정된 폴더구조로부터 프로젝트의 route를 도출해내도록 만들고있다. 즉 Next.js는 App dir기반의 라우팅을 제공하며 파일이름이 곧 경로의 이름이 되며 동적 경로의 경우 [id].js와 같은 파일명을 통해 지정해준다.

App Router

• 서버 중심 라우팅
• React Server Components기반으로 구축되어있다.
• 경로 이동시 페이지를 다시 렌더링하지 않고, SPA처럼 URL만 업데이트
• app 디렉토리를 사용
  • 디렉토리로 경로를 정의
  • 페이지를 위한 모든 파일은 page.js
  • server-side API를 위한 파일은 route.js
• Pages Router보다 높은 우선순위를 가지고있다.
• app디렉토리 내에 root 레이아웃이 필수로 포함되야한다.
• Data Fetching이 동시에 가능하다
• Parallel Routes를 지원한다.
  • 동일한 레이아웃에서 하나 이상의 페이지를 동시/조건부 렌더링이 가능하다
• Interceipting Routes를 지원한다.
  • 현재 페이지의 컨텍스트를 유지하며 현재 레이아웃 내에서 경로를 로드할 수 있다.

src/app
├─layout.js // root layout. 필수
├─page.js // root page
├─a-page
   └─page.js
└─b-page
  └─page.js
  └─component.js // 라우팅과 관련없는 코드. 라우팅의 대상이 되지 않습니다
    └─b-subpage
    └─page.js

Pages Router

• 클라이언트 중심 라우팅을 지원한다 (CSR)
• pages 디렉토리를 사용
• pages 하위에 있는 모든 JS파일이 페이지/API의 경로가된다.
• 라우팅이 필요없는 불필요한 코드 또한 경로가 생긴다.
• Data Fetching과 component를 함께 배치할 수 없다.

src/pages
├─_app.js // root layout
├─index.js // root page
├─a-page.js
└─b-page
  └─index.js
   └─component.js // 라우팅과 관련없는 코드지만 b-page/component라는 경로가 생깁니다.
   └─b-subpage.js

2.Rendering

SSR

서버 사이드 렌더링은 페이지 요청 시 서버에서 페이지를 렌더링하여 완전히 구성된 HTML을 클라이언트로 전송하는 방식입니다. 서버는 클라이언트에게 완전히 렌더링된 페이지를 제공하므로, 초기 로딩 시 클라이언트에게 보여지는 콘텐츠가 완전한 상태로 나타납니다. 이는 검색 엔진 최적화(SEO)와 초기 로딩 속도 개선에 도움이 됩니다. Next.js에서는 getServerSideProps 또는 getInitialProps 함수를 사용하여 서버 사이드 렌더링을 구현할 수 있습니다. 또한 Next에서의 SSR에서는 DOM에 각 스크립트 코드를 하이드레이션 해주어 SSR이지만 페이지 새로고침 없이 웹 페이지와의 상호작용이 가능하도록 만들수있어 SPA처럼 작동하는 SSR웹앱을 만들수가 있다.

장점

1. 안전성 증가
   • 페이지를 서버에서 렌더링 미ㅊ 키 관리, API 호출, 데이터 검증 작업을 '서버'에서 처리
2. 웹 사이트 제공 범위 확대
   • 렌더링을 서버에서 담당하므로 자바스크립트를 사용하지 못하는 환경에서도 웹 페이지 제공 가능
3. 검색엔진최적화(SEO) 유리

단점

1. 자원 소모, 서버 부하 증가
   • SSR을 사용하면 '서버'가 필요
   • CSR이나 SSG는 클라우드 서비스에 배포하는 serverless 방식을 사용 가능하지만 SSR은 서버를 사용해야 함= 웹앱이 더 많은 자원을 소모하고 부하를 보이며 유지 보수 비용이 증가
2. 페이지 이동 시 요청 처리 시간이 더 길어짐
   • 페이지 렌더링 때마다 매번 데이터 접근 및 외부 API 호출 발생=> 해결: Next.js에서 이 성능을 향상 시킬 수 있는 기능 제공

CSR

클라이언트 사이드 렌더링은 초기 요청 시에는 빈 페이지를 받고, 클라이언트에서 JavaScript를 사용하여 페이지를 동적으로 렌더링하는 방식입니다. 서버는 단지 초기 렌더링에 필요한 정적 파일과 JavaScript를 제공합니다. 이후 클라이언트에서 데이터를 가져와 페이지를 동적으로 업데이트합니다. CSR은 매우 반응성이 뛰어나고 인터랙티브한 사용자 경험을 제공할 수 있습니다.

장점

1. 네이티브 앱처럼 부드러운 화면 전환
   • 전체 자바스크립트 번들을 다운로드
   • 다른 페이지로 이동할 때 서버에서 새로운 컨텐츠를 다운로드하지 않고 해당 컨텐츠로 바꿀수있다=> 컨텐츠 변경을 위해 페이지 새로고침 필요 없음
2. 페이지 전환 간에 효과 추가 가능
   • 화면전환간 인터렉션을 손쉽게 넣을 수 있다.
3. 지연 로딩 (lazy loading)
   • 페이지 표현에 최소로 필요한 HTML 마크업만 렌더링
   • 이후 버튼 클릭 등으로 띄우면 모달 관련한 마크업을 그때 리액트가 동적으로 생성
4. 서버 부하 감소
   • 전체 렌더링 과정을 모두 클라이언트에서 진행
   • Firebase와 같은 serverless 환경에서 웹앱을 제공하는 것도 가능

단점

1. HTML에 등록된 JS 코드와 CSS 파일을 클라이언트에서 받아서 적용
   • 초기 화면 로딩에 수 초가 걸릴 수 있음
     • 이 과정에서 사용자는 빈 페이지를 보고 있어야 함
2. 웹앱의 SEO에 불리
   • 크롤러 봇이 수집해갈 페이지 정보가 없음
   • 자바스크립트 번들이 전송될 때까지 기다리기때문에 성능 점수가 낮아짐

SSG

정적 사이트 생성은 빌드 시점에 미리 페이지를 렌더링하여 정적인 HTML 파일을 생성하는 방식입니다. 서버에 요청이 오면 미리 생성된 정적 파일을 제공하므로 서버의 부하를 줄이고 빠른 응답 속도를 제공할 수 있습니다. 정적 사이트 생성은 페이지가 자주 변경되지 않거나 모든 사용자에게 동일한 콘텐츠를 제공해도 되는 경우에 적합합니다. Next.js에서는 getStaticProps 함수를 사용하여 정적 사이트 생성을 구현할 수 있습니다.

장점

1. 캐싱 용이
   • 정적 페이지는 단순 HTML 파일
2. 서버 부하 없음
3. 웹 사이트 전반적인 성능 상승
   • 빌드 시점에 HTML 페이지를 미리 렌더링
     • 서버는 정적 파일을 보내기만 하고, 클라이언트는 파일을 받아서 표시만 함
   • 변하는 데이터가 없으므로 서버 측에 데이터 요청도 없음
     • API 요청에 따르는 지연 없음
4. 안전성 증가
   • 필요한 모든 정보가 미리 렌더링되어 있음
     • API를 호출하거나 DB에 접근 및 보호가 필요한 민감한 데이터를 다루지 않음

단점

• 웹 페이지를 한번 만들고 나면 다음 배포 전까지 내용이 변하지 않음

ISR

NextJS에서 제공해주고 있는 독특한 렌더링 방식으로 정적 페이지를 업데이트하고 다시 렌더링할 주기를 지정 할수 있다.
다량의 데이터를 가져와야하는 복잡한 대시보드를 예시로 들수있는데 호출되는 데이터가 자주 변하지 않는 데이터일때 SSG와 ISR을 함께 사용하여 특정 시간 동안 데이터를 캐싱할수있다.

즉 ISR을 사용하게 되면 getStaticProps함수를 호출해서 데이터를 호출한후 revalidate로 지정한 시간까지 중간에 데이터 변경 요청이 있더라도 getStaticProps함수를 호출하지 않으며 revalidate 시간이 지나고 이후에 들어오는 데이터 변경 요청에 대한 처리는 새로운 정적 페이지를 만든 후, 이전에 저장해둔 정적 페이지를 새로운 페이지로 덮어쓴다

또한 revalidate시간이 지났더라도 새로운 요청이 없으면 즉 데이터 변화가 없으면 새로운 정적 페이지를 빌드하지 않는다.

3.Data Fetching

Next13에서 새롭게 추가된 App 디렉터리에 있는 모든 컴포넌트들의 디폴트값은 서버 컴포넌트로 세팅되어 있기때문에 서버에서 데이터를 불러오는 작업을 별도의 추가적인 세팅 없이 바로 할 수 있다.

SSR

특징

• SSR은 각 요청마다 서버에서 페이지를 동적으로 렌더링합니다.
• 각 요청에 맞는 데이터는 getServerSideProps 함수를 사용하여 가져옵니다.

장점

• 실시간 데이터 가져오기 및 렌더링으로 항상 최신 콘텐츠를 표시할 수 있습니다.
• SEO에 좋으며 검색 엔진이 완전히 렌더링된 콘텐츠를 쉽게 색인화할 수 있습니다.
• 인증 및 개인화된 콘텐츠에 적합합니다.

단점

• 초기 페이지 로딩이 SSG에 비해 느릴 수 있으며, 서버 부하가 증가할 수 있습니다.

SSG

특징

• SSG는 페이지를 빌드 시간에 사전 렌더링하여 정적 HTML 파일로 생성합니다.
• 초기 데이터는 getStaticProps 함수를 사용하여 가져오며, 데이터가 변경될 때마다 빌드 과정을 통해 페이지를 다시 생성합니다.

장점

• 초기 로딩 속도가 빠르고, SEO에 우수합니다.
• 정적 파일을 CDN에서 제공하여 전 세계 사용자에게 빠르게 서비스할 수 있습니다.
• 데이터 변경 시 재빌드가 가능하며, 재생성 간격을 설정하고 관리하지 않아도 됩니다.

단점

• 실시간 또는 사용자 특정 데이터에는 적합하지 않으며, 데이터 변경 시 빌드가 필요합니다.

ISR

특징

• ISR은 정적 사이트 생성 (SSG)과 서버 측 렌더링 (SSR)의 중간 지점에 위치하는 데이터 패칭 방식입니다.
• 초기 데이터는 getStaticProps 함수를 사용하여 빌드 시간에 가져오며, 페이지는 정적으로 렌더링됩니다.
• 페이지는 백그라운드에서 주기적으로 재생성 및 업데이트됩니다. 재생성 간격은 설정 가능합니다.
• 재생성 시에는 새로운 데이터로 페이지가 갱신됩니다.

장점

• 초기 로딩 속도가 빠르며, 사용자는 최신 데이터를 볼 수 있습니다.
• 정적 사이트 생성과 동일한 SEO 이점을 제공합니다.
• 데이터 변경 시 빌드를 다시 실행하지 않고도 페이지를 업데이트할 수 있습니다.
• CDN을 사용하여 전 세계 사용자에게 빠르게 서비스할 수 있습니다.

단점

• 재생성 간격을 설정하고 관리해야 하므로 설정에 신경을 써야 합니다.
• 너무 짧은 재생성 간격은 서버 자원을 낭비할 수 있고, 너무 긴 간격은 데이터가 오래된 상태가 될 수 있습니다.

Next.js 와 다른 프레임워크 비교

NextJS

1. 서버 사이드 렌더링(SSR) 및 정적 사이트 생성(SSG) 지원

• Next.js는 SSR과 SSG를 지원하여 페이지를 서버에서 렌더링하거나 정적 HTML로 사전 생성할 수 있습니다. 이로써 초기 로딩 속도를 향상시키고 SEO를 개선할 수 있습니다.
• SSR은 각 요청마다 서버에서 페이지를 동적으로 렌더링하고 최신 데이터를 표시합니다.
• SSG는 페이지를 빌드 시간에 사전 렌더링하여 정적 HTML 파일로 생성하며, 데이터가 변경될 때마다 재빌드할 수 있습니다.

2. 데이터 패칭 방식

• Next.js는 데이터 패칭을 위해 getStaticProps, getServerSideProps, 그리고 ISR(증분적 정적 재생성)을 제공합니다. 이러한 함수를 사용하여 페이지에 필요한 데이터를 효율적으로 가져올 수 있습니다.
• getStaticProps는 빌드 시간에 데이터를 가져오고, SSG와 ISR에 사용됩니다.
• getServerSideProps는 각 요청에 맞는 데이터를 서버에서 가져옵니다.
• ISR은 데이터를 주기적으로 업데이트할 수 있는 방식으로 정적 페이지를 유지하면서도 데이터를 최신 상태로 유지할 수 있습니다.

3. 내장 라우팅 및 네비게이션

• Next.js에는 내장된 라우팅 시스템이 있어 페이지 간 이동과 네비게이션을 쉽게 구현할 수 있습니다. Link 컴포넌트를 사용하여 클라이언트 사이드 라우팅을 손쉽게 설정할 수 있습니다.

4. TypeScript 지원

• Next.js는 TypeScript와 함께 사용할 수 있어 코드의 타입 안정성을 제공합니다. TypeScript 사용자에게 이점을 제공합니다.

5. DevOps 및 배포 지원

• Vercel과의 통합을 통해 개발, 빌드, 배포, 호스팅 등을 용이하게 관리할 수 있습니다. 개발팀과 운영팀 간의 협업을 향상시킵니다.

6. React 컴포넌트 기반

• Next.js는 React 컴포넌트를 기반으로 하므로 React 생태계의 이점과 컴포넌트 재사용성을 활용할 수 있습니다. 이는 개발 생산성과 코드의 모듈성을 높입니다.

장점

• SEO 최적화와 초기 로딩 속도 개선을 위한 SSR 및 SSG 지원.
• 데이터 패칭 방식과 내장 라우팅으로 개발 생산성 향상.
• TypeScript 지원으로 코드 안정성을 높일 수 있음.
• Vercel과의 통합으로 쉬운 배포 및 호스팅 가능.

단점

• React에 익숙해야 하며, 학습 곡선이 높을 수 있음.
• 프로젝트 규모가 커질수록 코드 관리와 구조가 복잡해질 수 있음.

VueJS

1. 진입 장벽 낮음

• Vue.js는 학습 곡선이 낮아 초보자에게 적합한 프레임워크로 평가됩니다. 가볍고 직관적인 문법을 갖추고 있어 빠르게 시작할 수 있습니다.

2. 컴포넌트 기반

• Vue.js는 컴포넌트 중심의 아키텍처를 채택하여 재사용성을 높이고 복잡한 UI를 모듈화할 수 있습니다. 컴포넌트 단위로 개발을 진행할 수 있습니다.

3. 단일 파일 컴포넌트

• Vue.js는 단일 파일 컴포넌트(Single-File Components)를 지원하여 HTML, CSS, JavaScript 코드를 한 파일에 구성할 수 있습니다. 이로써 코드 관리와 가독성이 향상됩니다.

4. 반응형 데이터 바인딩

• Vue.js는 화면과 데이터 사이의 연결을 쉽게 설정할 수 있는 반응형 데이터 바인딩을 제공합니다. 데이터의 변경이 자동으로 화면에 반영됩니다.

5. Vue CLI

• Vue CLI는 Vue.js 프로젝트의 생성, 관리, 빌드, 테스트 등을 위한 명령줄 도구를 제공합니다. 프로젝트 설정을 쉽게 관리할 수 있습니다.

6. 상태 관리

• Vue.js는 Vuex를 사용하여 상태 관리를 용이하게 할 수 있습니다. 복잡한 애플리케이션의 상태를 중앙에서 효과적으로 관리할 수 있습니다.

장점:

• 런닝커브가 낮고, 초보자에게 적합한 문서와 커뮤니티가 강력함.
• 컴포넌트 기반 아키텍처와 단일 파일 컴포넌트로 코드 구성 및 유지 보수가 용이함.
• 반응형 데이터 바인딩과 Vuex를 통한 상태 관리로 개발 생산성 향상.

단점:

• SEO 최적화를 위한 SSR 기능은 Vue.js 자체에 내장되어 있지 않아 추가 작업이 필요함.
• 상대적으로 작은 생태계로, React에 비해 다양한 라이브러리와 플러그인이 제한적일 수 있음.
• 큰 규모의 애플리케이션 개발 시 구조 및 모듈화에 관한 고려가 필요함.