App router방식을 사용하기로 결정!

Next App/Page Router

• Next는 13버전부터 App Router방식을 지원한다.

주요 변경사항

app Directory

- app/ 하위의 디렉토리의 `page.js`가 해당 경로의 컴포넌트가 된다.

app/
	page.js     <- 컴포넌트
	dashboard/
    	page.js <- 컴포넌트

Layout

- 공통적인 UI를 감싸는 형태의 컴포넌트로, 디렉토리내 `layout.js`를 정의하면, 하위의 디렉토리 컴포넌트에 공통적으로 적용된다.

app/
	page.js
	layout.js
    dashboard/
    	page.js    <- app/layout과 함께 렌더링된다.

React Server Component

• React v18에 도입된 개념으로, 서버에서 렌더링되는 컴포넌트를 의미한다.
• 장점
  • API latency감소 : 서버에서 데이터를 가져와 렌더링되므로, 클라이언트에서 API호출하지 않는다.
  • 서버 리소스 접근 : RCC는 API를 통해 리소스를 가져옵니다. 하지만 RSC는 서버에서 직접 접근하여 데이터를 가져오기 용이합니다.
  • 번들링 사이즈 감소 : 라이브러리를 통해 렌더링된 내용을 render하여 전달하므로, 라이브러리의 번들이 포함되지 않아, 전달되는 번들 사이즈가 감소합니다.

Streaming

• UI단위를 점진적으로 렌더링합니다.
• 데이터가 필요하지 않은 컴포넌트는 즉시 렌더링하고, 데이터가 필요한 컴포넌트는 로딩을 적용한 뒤, 렌더링합니다.

Data Fetching

• fetch() API를 통해, 컴포넌트의 SSR, SSG, ISR적용이 가능하다.

// page router에서의 getStaticProps와 유사하며, SSG적용
fetch(url, { cache: 'force-cache' })

// page router에서의 getServerSideProps와 유사하며, SSR적용
fetch(url, { cache: 'no-store' })

// page router에서의 getStaticProps와 유사하며, 10초 간격으로 데이터를 새로 불러오는 ISR적용
fetch(url, { next: { revalidate: 10} })

잠깐! SSR? SSG? ISR?

• SSR은 요청이 있을 때마다, 서버에서 새로 렌더링하는 컴포넌트를 말한다. (데이터가 매번 새로 필요함)
• SSG는 빌드타임때만 렌더링/캐싱처리하여, 요청시 매번 같은 내용의 컴포넌트이다. (데이터가 1회만 필요함)
• ISR은 SSG와 SSR의 중간즈음으로 생각하면 되는데, 옵션으로 설정한 10s마다, 서버에서 새로 빌드/캐싱처리하여, 내려주는 것이다.
  • 즉, 10초마다 SSG를 만든다고 생각하면 된다.

ISR이 왜 필요함? "데이터가 일정간격으로 바뀐다면, 필요함!"
SSG는 SSR에 비해, 매번 렌더링할 필요가 없어 서버의 부하를 최소화해준다. 그래서 되도록이면, SSR보다는 SSG를 작성하려 노력해야 한다.
하지만, 일정 간격마다 데이터가 필요한데 SSG를 작성하는 것은 어려우므로, 일정한 간격마다 SSG를 생성하여, 덜SSR같이 만드는 것이다.

마무리

• 여기까지가 next13으로 업데이트 되면서, app router방식과 page router방식의 차이점이었다.
  (물론 버전이 업데이트 되면서, next/image, turbopack향상 등이 있지만, app router와는 무관한 내용이다)
• 이러한 변경점을 보았을 때, 기존 page보다는 app router방식이 더 효율적으로 사용할 수 있을 것으로 보인다. (next공식문서에도 추천하고 있다.)

참고사이트

• [Next.js] Next.js 13 변경사항
• 카카오블로그 - React 18: 리액트 서버 컴포넌트 준비하기