[04] 앱라우터와 페이지라우터의 차이점이 뭔가요? 왜 앱라우터를 채택했나요?

📎 질문

앱라우터와 페이지라우터의 차이점이 뭔가요? 왜 앱라우터를 채택했나요?

✏ 구술 답변 키워드

앱 라우터의 장점을 키워드로 잡겠습니다.

리액트의 Server Component, Suspense기반 layout.js, loading.js, error.js 제공 => 코드 단순화 발전된 fetch API 제공(cache, revalidate)

✏ 서술 답변

Next.js에는 App router와 Page router 두 가지 라우팅 방식이 있습니다. Page router는 기존의 방식이며, 리액트의 최신 기술인 Server Component와 Suspense을 사용할 수 있는 App router가 최근에 등장했습니다. Next13.4부터 App router가 안정화 되었고 많은 변화가 생겼습니다.

1. 라우팅 디렉토리 및 파일

Next.js이 파일 기반 라우팅 시스템인 점은 동일합니다. Page router의 page디렉토리가 app디렉토리로 바뀌었으며 _app, _document는 layout.js로 대체됩니다. layout.js는 중첩된 레이아웃 사용을 편리하게 하고 코드를 단순화합니다. 앱 라우터는 loading.js와 error.js를 제공하여 코드를 단순화합니다.

2. 서버 사이드 렌더링

Page router에서는 서버 사이드 렌더링을 위해 getServerSideProps를 사용해야 했습니다. App router는 서버 컴포넌트 기반이기 때문에 fetch와 async/await 문법을 사용하여 서버 데이터를 가져올 수 있습니다.

3. Suspense

getServerSideProps를 사용하면 전체 페이지가 수화될 때까지 애플리케이션과 상호 작용이 차단되었습니다. 그러나 앱 라우터는 React의 Suspense로 페이지의 일부를 선택적으로 수화하고 다른 UI 컴포넌트를 상호 작용할 수 있게 차단하지 않습니다.

  return (
    <section>
      <Suspense fallback={<p>Loading feed...</p>}>
        <PostFeed />
      </Suspense>
     <Dashboard/>
   </section>)

4. 발전된 fetch API 제공

App router에서 제공하는 fetch API는 caching과 revalidate를 제공합니다. 데이터 요청 시 캐시된 값이 있다면 api재요청을 하지 않아 서버 부하가 감소하고 성능이 개선됩니다.

앱 라우터, 페이지 라우터

Next.js는 13버전을 기준으로 앱 라우터로 서버 중심 라우팅 기능을 지원합니다.

라우팅

App router: 서버 중심의 라우팅

react server components 기반으로 구축되어 있다.
경로 이동 시에 다시 렌더링 하지 않고, SPA처럼 동적으로 URL 이동 시에 변경된 지점만 렌더링하여 업데이트 한다.
기본적으로 파일 생성 시에 서버 컴포넌트로 생성되며, 클라이언트 컴포넌트로 만들기 위해서는 최상단에 ‘use client’를 명시해주어야 한다.

Page Router: 클라이언트 중심의 라우팅

디렉토리, 레이아웃

App router:

app 디렉토리가 베이스 디렉토리.
page.js: 페이지를 생성하는 파일
다양한 라우팅 폴더 명명 방식으로 기능을 분리할 수 있다. ex) (폴더명)
app 디렉토리 내 root layout을 필수로 포함해야 한다.

Page Router:

pages 디렉토리가 베이스 디렉토리.
pages 하위에 있는 파일이 url 경로가 된다.

렌더링

작성한 코드를 사용자 인터페이스로 변환하는 것. NEXT는 모든 경로의 페이지에 대한 HTML 파일을 사전에 렌더링한다. 브라우저에서 해당 페이지 경로 접근 시, HTML과 연결된 최소한의 JS 파일이 전달되고, JS 가 실행되면서 하이드레이션 과정이 일어난다.

SSG (Static Site Generation)

App Router
- fetch({cache: ‘force-cache’})의 옵션 혹은, generateStaticParams 함수로 구현한다. (revalidate 하기 전까지의 데이터가 캐싱되는 방식)
- Server component: 사전 렌더링 되어 HTML을 생성한다. JSON을 미리 렌더하고 서버에 캐싱된다.
page router
- app router의 클라이언트 컴포넌트와 동일하게 작동한다.

SSR (Server Side Rendering)

App Router:

Dynamic Rendering이라고도 불린다.
일반적인 fetch() 함수를 통해서 페이지에서 비동기로 사용하여 서버사이드 렌더링 구현 가능
페이지 컴포넌트에 async 필요하다. (fetch 함수 사용하여)

Pages router

getServerSideProps라는 함수를 사용해야 했다.

Data Fetching

App Router:

fetch() Web API를 사용할 수 있게 되어, SSR data fetching 방식이 변경되었다. 기존의 getStaticProps, getServerSideProps, getStaticProps 방식을 fetch()옵션으로 대체할 수 있다.
react server component로 서버 데이터를 가져옵니다. 서버에서 데이터를 가져오면 다음과 같은 장점이 있습니다.
- 서버 데이터베이스 리소스에 직접 접근이 가능하여 민감한 정보가 클라이언트에 노출되지 않는다.
- 성능이 향상된다.
- 빌드 시에 자동으로 데이터 fetching이 이루어지고 캐싱된다.
- useEffect를 사용하여 데이터를 페칭하고 상태를 변경하는 방식에서 벗어난다.
pages router:
- getinitilaProps, getServerSideProps, getStaticProps 를 통해서 data를 필요한 시점에 가져온다.

리스티웨이브 앱 라우터 선정 이유

리스티 웨이브에서 앱 라우터 방식을 선택한 이유는 다음과 같은 목적이 있습니다.

학습 목적: 서버 중심의 라우팅 방식을 기반으로 웹 애플리케이션을 구축하면서 페이지 라우터와의 차이점을 실제로 경험해보고자 하는 목적
SSR 렌더링을 활용하여 SEO에 최적화된 애플리케이션: 검색 엔진 최적화를 위해 SSR 렌더링에 최적화된 앱 라우터 버전을 사용하고자 함.
리액트 서버 컴포넌트 사용: 서버 컴포넌트 사용 시, 초기 페이지 로딩 속도가 빨라짐. 빠른 페이지 접근이 필요한 곳에서 사용하기 위함

Next.js 13 버전은 App Router를 도입하여 웹 애플리케이션에서 서버 중심 라우팅 기능을 제공합니다. 이것은 웹 페이지 간의 전환을 더 효율적으로 만들어주며, 특히 페이지의 일부만 변경되는 경우, 전체 페이지를 다시 불러오지 않고 필요한 부분만 업데이트 하는 방식으로 작동합니다. 이를 통해 단일 페이지 애플리케이션(SPA)처럼 부드러운 사용자 경험을 제공합니다.

App Router와 Page Router의 차이 App Router 기반 구조: React의 서버 컴포넌트를 사용하여 구축되며, 주로 서버에서 실행되는 컴포넌트들로 구성됩니다. 디렉토리: app 디렉토리가 기본이며, 여기에 모든 라우팅 및 페이지 구성이 포함됩니다. 렌더링: 변경된 부분만 동적으로 업데이트하여 렌더링하며, 서버에서 사전 렌더링된 컴포넌트를 통해 초기 로드 시 HTML을 제공합니다. 데이터 페칭: fetch API를 활용하여 서버에서 데이터를 직접 가져올 수 있으며, 민감한 데이터는 클라이언트에 노출되지 않습니다. Page Router 기반 구조: 전통적인 클라이언트 중심의 라우팅 방식을 따르며, pages 디렉토리에 각 페이지 파일이 위치합니다. 디렉토리: pages 디렉토리가 URL 경로로 직접 매핑되어, 파일 구조가 그대로 URL 구조를 반영합니다. 렌더링: 클라이언트 측에서 JavaScript를 통해 페이지를 동적으로 렌더링하며, 필요할 때마다 새로운 데이터를 불러와 페이지를 업데이트합니다. 데이터 페칭: getServerSideProps와 같은 Next.js 특화 함수를 사용하여 서버에서 데이터를 가져옵니다.

차이

App Router는 React 18 버전 기능인 RSC, Suspense 등을 도입한 최신 라우터이다. 즉, Page Router 보다 App Router가 더 많은 기능을 제공한다.
디렉토리 구조 및 문법이 상이하다.

앱 라우팅을 채택한 이유

13.4.0 버전 이후 안정화되었고, 유망한 최신 기술이기 때문에 장기적으로 유지 보수하기에 보다 적합하다.
필요한 기술적 이점을 제공한다.
- 페이지 라우팅에서는 SSR이나 SSG 전략을 페이지 단위로 getServerSideProps, getStaticProps 같은 함수를 통해 구현할 수 있었지만, 앱 라우팅은 디폴트가 RSC(React Server Component)이고 컴포넌트 별로 SSR, CSR 전략을 선택할 수 있다.
- 추후 패러렐 라우트, 인터셉트 라우트를 통해 모달을 페이지화 할 수 있다.

페이지 라우터

클라이언트 중심 라우팅 방식 : 애플리케이션의 개별 페이지 내에 라우팅 처리를 하고 이를 통해 동적 경로를 만들고 특정 콘텐츠를 렌더링하기 위한 경로 파라미터에 접근할 수 있음
프로젝트 구조 : 각 개별 페이지 구성요소에 구현
서버 컴포넌트 지원하지 않음

앱 라우터

서버 중심 라우팅 방식 : 전체 애플리케이션에 대한 전반적인 라우팅 및 탐색을 처리. URL을 기반으로 올바른 페이지를 렌더링하고 페이지간 전환을 관리함
프로젝트 구조 : _app.js 파일에 구현되어 전체 애플리케이션을 래핑함(폴더 구조를 이용해 라우팅 - 각각의 파일이 경로 역할)
서버 컴포넌트 지원

앱 라우터를 채택한 이유

서버 컴포넌트를 통해 프로트 서버에서 HTML을 빌드해 클라이언트로 보내는데, 클라이언트로 전송되는 JS 코드 양을 줄이고 복잡한 인터페이스를 구축할 수 있어 초기 페이지 속도를 빠르게 해주는 이점이 있음
Next.js에서 기본적으로 제공되는 fetch API를 통해 별도의 캐싱 및 Props 전달 없이 필요한 곳에서 바로 데이터 핸들링이 가능한 특징 존재

앱라우터와 페이지라우터의 가장 큰 차이점은 RSC(React server component)사용의 유무에 있습니다. RSC를 도입하고 싶다면 AppRouter방식을 채택하고, 클라이언트 컴포넌트를 사용하고 싶다면 PagesRouter를 사용하면 됩니다.

지난 프로젝트에서 next.js의 페이지라우터를 사용하였는데, 리액트와 크게 성능 차이를 느끼지 못했습니다. 페이지라우터로 SSR을 사용한다고 해도, 컴포넌트는 클라이언트 사이드에서 렌더링이 되기 때문에 사용자에게 페이지를 보여주려면 클라이언트 측에서 JavaScript 번들을 다운받아야 합니다. 결국 CSR과 동일한 사이즈의 js번들을 다운 받아야 하기 때문에 사용자 입장에서는 TTI에 큰 메리트가 없다고 느껴졌습니다.

하지만 RSC를 도입하면 컴포넌트가 서버에서 한차례 렌더링 되기 때문에 번들이 필요하지 않습니다. RSC의 컴포넌트 소스 파일 뿐 아니라 RSC를 사용하는 외부 라이브러리도 번들이 필요하지 않기 때문에 번들 사이즈를 줄여 TTI 개선에 기여할 수 있습니다. 또한 앱라우터 환경에서는 클라이언트는 먼저 수신된 부분부터 반영하기 때문에, 실제로 TTI개선을 체감할 수 있었습니다.

또한 서버에 접근해서 Data Fetch를 하는 방식에 차이가 있습니다. 페이지라우터에서는 getServerSideProps/getStaticProps함수를 페이지 최상단에서 수행하고 props로 넘겨서 사용하여야 했기 때문에 실제로 사용하는 하위 컴포넌트까지 props drilling이 불가피했습니다. 하지만 RSC는 그 자체가 서버에서 렌더링 되므로, 사용하는 컴포넌트에서 직접 Data Fetch가 가능하기에 getServerSideProps/getStaticProps를 사용하지 않아도 되는 편리함이 있습니다.

앱라우터, 페이지 라우터의 차이

앱라우터는 app/ 디렉토리를 생성해 라우팅을 설정할 수 있다.
라우팅의 환경이 개선되었다.
기존의 _app.tsx와 비슷한 개념인 Layout을 제공한다.(layout.js)
app/ 디렉토리 내 모든 파일은 디폴트로 서버컴포넌트로 동작한다. ( 클라이언트 컴포넌트에는 상단에 'use client' 명시.
app/ 디렉토리는 렌더링되는 UI 단위를 점진적으로 렌더링 / 스트리밍 할 수 있다. ( skeleton UI )
fetch() Web API를 사용할 수 있게 되어 컴포넌트 레벨에서도 SSR적용이 가능하다.

앱라우터 채택 이유

SNS이므로 SEO를 중요시했다. 어디서든 검색이 되어 많은 사용자 유치를 계획했다.
마찬가지로 SNS이므로 첫 화면의 로딩속도를 중요시했다. 로딩이 느려 웹사이트 사용하기를 포기하는 상황을 우려했다.
최신 기술에 대한 관심도 있고, pages router를 next 공식 홈페이지에서도 지양하고 있기때문에 app router를 사용했다.

앱라우터 사용시 단점

app/ 디렉토리에 페이지들을 모두 생성했으나, proxy문제로 pages/ 경로또한 생성했어야하는 문제점이 있었다. 추후 업데이트 될것이라 예상된다.

QueenCards / ProjectAnalysis