# 서론
nextjs 13 부터는 App Router라는 방식이 새로 나왔고, 공식 문서와 creat-next-app@latest을 사용해보더라도 이 방식을 권장하고 있는 것을 볼 수 있다. 하지만 언제나 그렇듯 어떤 것이 절대적으로 좋은 경우는 없었다. 이 둘을 비교해 보고 어떤 것을 적용할지 정해보려 한다.
# Next.js의 라우터
Next.js는 react와는 다르게 폴더 구조를 기반으로 routing을 한다. 간단하게 App Router와 Pages Router의 차이를 표로 먼저 비교해보자.
| Pages Router | App Router | |
|---|---|---|
| Directory | pages | app |
| Navigate | client-side | client-side |
| Routing | client-side | server-centric |
| Server Component | No | Yes |
위 표를 토대로 좀 더 자세하게 비교해보자.
# Directory (Routes)
1. Pages Router
먼저 Pages Router의 경우 pages폴더의 디렉토리 구조에 따라 페이지 경로가 정해진다.
개별 페이지 내에서의 라우팅에 초점을 맞춘다.
pages/index.js -> /
pages/blog/index.js -> /blog
pages/dashboard/settings/username.js -> /dashboard/settings/username
pages/posts/[id].js -> post/1, post/2
2. App Router
App Router는 app폴더의 디렉토리 구조를 따라 경로가 정해진다. 다만 App Router에서는 해당 경로에 속한 파일명을 index.js가 아닌 page.js로 놓는다.
전체 Application의 routing과 navigation을 포괄적으로 담당한다. ex) url 영향 없이 라우팅 그룹화, multiple root layout만들기, intercepting routes 등 디렉토리 구조만으로도 다양한 시도를 할 수 있다. 이런 관점에서 App Router가 더 유연하다고 하는 것 같다.
app/page.js -> /
app/blog/page.js -> /blog
app/dashboard/settings/username/page.js -> /dashboard/settings/username
app/blog/[slug]/page.js -> blog/a -> params: { slug: 'a' }
# Linking And Navigate
1. Pages Router
Pages Router는 client-side-routing, client-side navigation이다.
react-router와 별 차이가 없다. 이 말은 client에서 routes list를 포함하는 js code를 가지고 있어야 한다는 말이다.
2. App Router
App Router는 pages directory와는 다르게 라우팅은 server-centric routing, 네비게이션은 client-side Navigation이다.
다음과 같은 순서로 작동한다.
- A. 라우팅과 관련된 컴포넌트들을 모두 서버에서 빌드하여 클라이언트에게 보내준다. (
Server-centric Routing) - B. 버튼 클릭을 통한 네비게이션과 같이 유저 상호작용등을 구현한 js코드를 클라이언트에 보낸다.
- C. 클라이언트 단에서 Navigation을 한다. 이 때, 페이지를 리로드 하는 것이 아니라 SPA처럼 변화가 있는 부분만 렌더링 한다. (
Client-Side Navigation)
정리해보면 App Router의 routing은 hydration으로 동작한다. hydration은 먼저 ui와 관련된 부분들과 서버에서 요청할 수 있는 data를 미리 fetch하여 빌드하고 클라이언트에 보낸 뒤, 후에 js bundle을 보낸다. 클라이언트는 이를 파싱할 필요없이 바로 브라우저에서 렌더링한다.(Time To View) 그리고 서버에서 유저 상호작용과 같은 js code를 보내준다. 클라이언트에서 이 js code가 로드되면 이때부터 사용자의 상호작용이 가능해진다.(Time To Interaction)
이렇게 되면 클라이언트가 굳이 무거운 라이브러리를 사용하여 서버에 data를 요청할 필요도 없고, 브라우저는 js를 파싱할 필요도 없다. 한마디로 퍼포먼스가 향상되고, 초기 로딩이 빨라진다.
이것이 SSR이고 hydration인데 router와 관련해서 Next12의 경우 hydration이 되지 않았고, 이를 13에서 개선시킨 모양이다.
# App Router의 장점?
1. 성능
Server Component를 통한 성능 향상, 번들 사이즈 감소 등 성능적인 면에서는 장점이 확실하다. 13버전은 결국 12에서의 단점들을 개선해서 내놓은 것이니 성능적인 부분에서 우위가 있는 것은 당연한 것 같다.
2. layout, loading, error 핸들링
파일명 layout.js, loading.js, error.js를 통해 app 폴더 내에서 페이지 별로 핸들링이 가능해졌다. 이를 통해 가독성은 확실히 좋다는 생각이다.
# App Router의 단점?
App Router의 장점도 많았지만 구글링을 하다보니 비판하는 글도 자주 보였다. 간단히 정리해보면 다음과 같다.
1. 난잡한 App 폴더 구조.
아무래도 폴더구조와 파일명을 통해 다양한 기능을 제공하다보니 난잡해진다. 근데 이건 Pages 폴더에서도 다른 방향으로 단점으로 지적되온 부분인 것 같다.
2. 지원하지 않는 라이브러리
App Router가 나온지 얼마 되지 않다보니 App Router를 지원하지 않는 라이브러리가 많다. 이는 시간이 지나면 해결되지 않을까 싶다.
3. Server Component와 CSS-in-js
공식 문서를 확인한 결과, 현재 CSS-in-js를 server component에서 지원하지 않는다.
# 결론
성능적으론 우위에 있지만 아직 불안정한 것들이 많은 것 같다. 물론 내가 Pages Router는 사용을 해보지 않아서 순전히 구글링을 통해 내린 결론이다.
1. App Router를 사용하는 경우
Server Component를 통한 성능 개선이 하고 싶다면 추천
2. Pages Router를 사용하는 경우
App Router의 버그, server components에서 SSR을 지원하지 않는 라이브러리 등의 문제를 피하고 싶은 경우
위와 같이 경우를 나눠보았지만, 13버전도 점점 안정화 되어 가고 있는 느낌이고 나중엔 모두가 App Router를 쓰고 있을 것 같다. 그리고 Pages Router를 사용하던 개발자 분들의 App Router에 대한 적나라한 욕설 담긴 글들을 간간히 접했는데, 버그 문제도 있겠지만 이것들도 결국 생소한 것을 접했을 때 인간의 거부 반응이 아닐까 싶다. (아 물론...나는 Page Router는 사용해 본적이 없기 때문에 그냥 개인적인 추측이다)
팀원과 상의한 결과, 우리 팀원은 Page Router를 통해 프로젝트를 여러번 진행해 보셨고, 안정적으로 Page Router를 사용하고 싶어한다. 또한 우리는 Emotion을 사용할 것인데 CSS-in-js를 지원하지 않는 것도 주요한 문제다. 나도 Page Router / App Router 둘 다 사용해 보는게 경험적인 면에서도 좋을 것 같고, 필요하다면 추후에 App Router로 마이그레이션을 해보는 것도 좋을 것 같아서 Page Router를 사용하기로 했다.
