Page Router

Page Router의 장점

파일 시스템 기반의 간편한 페이지 라우팅 제공

추가적인 코드의 작성 없이 매우 편리하고 간편하게 페이지의 라우팅을 처리

동적 경로를 사용하는 다이나믹 페이지의 경우 대괄호를 통해서 하나의 URL 파라미터에 대응

[...id]처럼 캐치홀 세그먼트를 설정해 중첩된 모든 URL 파라미터에 대응하도록 설정하거나

[[...id]] 처럼 옵셔널 개치홀 세그먼트를 설정해서 인덱스 페이지까지 포함하면서 동시에 중첩된 모든 URL 파라미터에도 대응하도록 설정 가능

✨ 폴더 구조만으로도 원하는 대로 자유롭게 페이지의 라우팅을 설정 가능

다양한 방식의 사전 렌더링 제공

서버사이드 렌더링(SSR)

• 요청이 들어올 때마다 사전 렌더링을 진행
  요청을 받을 때마다 매번 새롭게 페이지를 생성하기 때문에 항상 최신의 데이터를 보장할 수 있다는 장점이 있지만
  페이지를 새롭게 생성하는 과정에서는 백엔드 서버에게 데이터를 요청해야 된다면 발생하는 딜레이로 인해 상황에 따라 응답 속도가 크게 느려지게 되는 단점이 존재합니다.

정적 사이트 생성(SSG)

• 빌드 타임에 미리 페이지를 사전 렌더링 해 둠
  빌드 타임(Build Time)에 미리 Next.js 서버 측에서 페이지를 정적으로 생성해 두기 때문에 백엔드 서버에게 데이터를 요청하는 시간이 오랜 시간이 소요된다고 하더라도 모두 서버 가동 이전에 빌드 타임에만 일어나는 일이기 때문에 빌드가 완료된 이후에 발생하는 접속 요청에는 미리 만들어둔 페이지를 매우 빠른 속도로 응답할 수 있기 때문에 SSR 방식의 문제점을 효과적으로 해결한다는 장점이 있지만
  그러나 반면에 빌드 타임 이후에는 페이지를 재생성하지 않기 때문에 매번 똑같은 페이지만 응답하게 되어 최신 데이터를 반영하기 어렵다는 단점이 존재

증분 정적 재생성(ISR)

• SSG 페이지 일정 시간마다 재생성
  SSG 방식으로 빌드타임에 미리 생성된 정적인 페이지에 유통기한을 설정해둬서 유통기한이 지나기 전까지는 원래 만들어두었던 페이지를 SSG 방식 그대로 응답 해주다가 유통기한이 끝나게 되면 이때 페이지를 다시 만들게 되어서 최신 데이터를 반영하도록 설정하는 장점과
  게시글 수정과 같은 유저의 특정 행동 이후에만 페이지를 다시 생성을 해야 되는 상황이라면 그때에는 On-Demand 방식으로 Next 서버에게 Revalidate 요청을 보내서 즉각적으로 다시 생성할수 있도록 설정할 수 있는 장점도 존재
  즉, 모든 케이스의 장점들을 가지고 있다고 정리를 할 수 있습니다.

---

Page Router의 단점

페이지별 레이아웃 설정이 번거롭다.

페이지별 레이아웃이 많아지게 된다면 코드의 중복이 발생하고 불필요하게 어려운 느낌이 존재합니다.
하지만 App Router에서는 더 편하게 파일 하나만 배치하는 것만으로도 페이지별로 레이아웃을 설정할 수 있는 좋은 기능을 제공합니다.

데이터 패칭이 페이지 컴포넌트에 집중된다.

Page Router는 서버에서 불러온 모든 데이터는 Page 컴포넌트에게 props로 전달이 되는 구조를 따르기 때문에 자식 컴포넌트는 데이터를 전달 받아야 됩니다. 페이지에 필요한 컴포넌트들이 많아 복잡해지는 경우 매우 복잡하게 된다는 단점이 존재합니다.

불 필요한 컴포넌트들도 JS Bundle에 포함된다.

최초로 화면에 컨텐츠가 렌더링 되는 FCP 시점 이후에 Next 서버가 후속으로 하이드레이션을 위해서 모든 컴포넌트들을 Javascript 번들로 묶어서 전달하는 과정에서 브라우저에게 전달될 필요가 없는 불필요한 컴포넌트들도 함께 폼하이 되어서 전달이 된다는 뜻입니다.
이때 불필요한 컴포넌트들이란 상호작용하는 기능이 없기 때문에 브라우저에서 한 번 더 실행이 되어 하이드레이션이 될 필요가 없는 그러한 컴포넌트들을 말합니다.

하이드레이션(Hydration)이란? HTML로만 되어 있던 자바스크립트 코드를 연결해서 사용자의 클릭이나 입력과 같은 다양한 이벤트 상호작용들을 추가하기 위한 작업