next js의 이해

시작하기

• next js는 빠른 웹 어플리케이션 구축을 위한 기본 구성을 제공하는 유연한 react 프레임 워크임.

• 이게 뭔소리지?

• 요즘의 어플리케이션을 만들려면 다음과 같은 걸 생각해야 함.
• UI, 라우팅, data fetching, 렌더링, integrations, etc..

• 리액트는 인터렉티브한 UI를 만들 때 사용하는 라이브러리임.

• 물론 리액트가 UI를 만들 때 유용한 기능을 제공하지만, 이러한 기능을 어디에 놓을지는 개발자들이 정하게 됨.

• 어쩌면 이런 게 서드파티와 다른 솔루션들이 범람하는 생태계를 만든 요인일지도!?

• 이는 즉, 개발자들은 여러 툴을 학습하느라 시간을 보내야 한다는 뜻임.

• 그래서 next js가 이러한 문제를 해결하려 등장함!
• 최종 사용자들의 경험을 향상시키기 위한 routing, data fetching 것들 지원함.

Next.js의 장점

• 다음을 중점적으로 보자!
• 어디에서 코드가 돌아가는지 : Development vs. Production
• 언제 코드가 돌아가는지 : Build Time vs. Runtime
• 어디서 렌더링이 되는지 : Client vs. Server
• network

• next js는 개발 단계 그리고 프로덕션 단계에서 다음과 같은 장점이 있음.
• 개발 단계) DX 향상 : TypeScript, ESLint integration, Fast Refresh, compiled, bundled, minified, code split
• 프로덕션 단계) 실유저에게 코드를 더 접근 가능하게 보여줌.

• Compiling
• 컴파일링은 한 언어에서 다른 언어나 버전으로 옮기는 과정임.

• Minifying
• 개발자는 코드를 인간 친화적이게 작성함.
• 하지만 이런 코드는 코드를 동작하는데 불필요한 추가 정보를 포함함. ex) 주석, 공백, 줄바꿈
• Minifying은 코드의 기능을 바꾸지 않고 불필요한 포맷팅 코드와 주석을 제거하는 과정을 말함.

• Bundling
• 개발자는 모듈, 컴포넌트, 함수 등으로 어플리케이션을 나눔.
• 이러한 모듈(+ 서드파티)을 export하고 import하면서 복잡한 파일 의존성이 생김.
• Bundling은 브라우저의 웹 의존성을 해결하고 파일을 최적화된 번들로 통합함. 이로 인해, 유저가 웹페이지에 접속했을 때, 수많은 파일 요청을 줄일 수 있음.

• Code Splitting
• 개발자는 많은 페이지로 각각의 다른 url을 만들어 접속하게 함.
• Code Splitting은 각 진입점이 필요하도록 작은 chunks로 쪼개는 것을 말함.
• 이렇게 하는 이유는 그 페이지에 필요한 코드만 로드하게 함으로써 최초 로드되는 시간을 줄이기 위함임.
• next js는 pages/라는 디렉토리가 빌드 단계에서 자동으로 Code Splitting을 함.
• 뿐만 아니라, 페이지 간 공유 된 코드도 쪼갬. 그렇게 되면 같은 코드를 다시 다운받지 않을 수 있음.
• 최초 페이지가 로드된 후, next js는 다른 페이지에서 코드를 pre-loading할 수 있음.
• 동적 import로도 구현할 수 있음.

• Build Time은 프로덕션을 위한 코드를 준비하는 단계임.
• next js는 어플리케이션을 빌드할 때, 프로덕션에 최적화함.
• 정적 페이지를 위한 HTML 파일
• 서버에서 렌더링하는 JS 코드
• 클라이언트에서 동적인 요소를 위한 JS 코드
• CSS 파일

• Runtime은 빌드, 배포 이후 유저의 요청에 의해 어플리케이션이 돌아가는 시간을 말함.

• client : 서버에 요청을 보냄.

• server : 데이터를 저장하고, client로부터 요청을 받고, 계산하고, 응답함.

• rendering : 웹에서 돌아갈 수 있도록 코드를 변환하는 과정임.
• server, client 모두에서 일어나게 할 수 있음.
• build할 때, runtime의 모든 요청 모두에게 일어나게 할 수 있음.
• next js는 Server-Side Rendering, Static Site Generation, Client-Side Rendering 모두 가능함.
• Server-Side Rendering, Static Site Generation을 Pre-Rendering이라고도 함. client에게 결과물을 보여주기 전에 외부 데이터를 fetch하고, 변형하기 때문.

• Client-Side Rendering vs. Pre-Rendering
• 일반적인 react 어플리케이션은 빈 HTML을 브라우저에게 전달함(client-side rendering). 최초 렌더링이 유저의 기기에서 일어나기 때문.
🔖
next js에선 useEffect()나 useSWR을 통해 client-side rendering을 할 수 있음.
• 반대로 next js는 기본적으로 모든 페이지를 pre-render함.
• Pre-rendering은 유저의 기기에서 JS를 모두 불러오는 게 아닌, 서버에서 미리 HTML을 만드는 것을 의미함.
• client-side rendering은 유저가 코드를 불러오기 전까지 빈 화면을 보게 된다는 단점이 있음.
• server-side rendering은 각 요청마다 HTML이 그려짐.
• 그 후 페이지를 그리기 위한 HTML, JSON data, JavaScript instructions 생성되어 client에게 보내짐.
• client는 동적인 페이지를 빠르게 볼 수 있음. 이 과정을 hydration이라 함.
• react에도 hydration 있음.
• next js에선 server-side render를 getServerSideProps로 쓸 수 있음.
• next js의 아름다움은 페이지마다 적절한 렌더링 방법을 선택할 수 있다는 것임.

• next js는 미들웨어와 함께 edge에서 그리고 리액트 서버 컴포넌트에서 코드를 돌릴 수 있음.
• edge는 정적 콘텐츠를 저장하는 CDN(Content Delivery Network) 역할 뿐만 아니라, origin sever에서 하는 일부 역할도 수행함. ex) 캐싱, 코드 실행
• 이때 유저에게 가까운 서버에서 실행하기 때문에 더욱 효율적으로 sever의 부담을 줄여줄 수 있음 (latency 감소).