Next.js 왜 쓰는거야?

React는 UI를 편리하게 해주는 라이브러리다.

Next.js는 React를 사용하여 Web을 만드는 프레임워크이다.

 

라이브러리란? 특정한 문제를 해결하기 위한 툴

프레임워크란? 큰 단위의 솔리션을 위한 골격을 제공해준다. 여기에는 특정한 문제를 해결하는 툴도 포함되어 있다.

 

Next.js

• Full Stack을 가능하게 해준다.
• 파일을 베이스로 한 Routing을 해준다.
• SEO, Image, Font 최적화를 해준다.
• Server Side Render, Static Site Generation을 가능하게 해준다.
• 하이브리드 렌더링을 기능하게 해준다.

 

Next.js는 2016년에 gitHub 오픈소스로 공개되었다.

Vercel이란 회사에서 만들었는데 Vercel은 미국의 클라우드 플랫폼 (PaaS 서비스)을 제공하는 회사다.

PaaS라고도 하는 Platform as a Service는 일종의 클라우드 컴퓨팅 서비스 모델로서 앱을 개발, 배포, 실행, 관리할 수 있는 유연하고 확장 가능한 클라우드 플랫폼을 제공합니다. PaaS는 애플리케이션 개발에 필요한 모든 것을 개발자에게 제공합니다. 운영체제와 개발 도구를 업데이트하거나 하드웨어를 유지보수할 필요도 없습니다. 대신 전체 PaaS 환경 또는 플랫폼을 타사 서비스 제공업체에서 클라우드를 통해 제공합니다. 
PaaS는 기업에서 새로운 커스텀 애플리케이션을 개발하거나 호스팅하기 위해 하드웨어나 소프트웨어를 설치해야 하는 번거로움과 비용을 없애는 데 도움을 줍니다. 개발팀에서 인프라, 개발 도구, 운영체제 등 커스텀 앱을 빌드하는 데 필요한 모든 것에 대한 액세스 권한을 사용한 만큼만 지불하는 방식으로 구매하게 됩니다. 
덕분에 더 쉽고 빠르며 안전한 앱 개발이 가능하여 개발자가 애플리케이션 코드에 집중할 수 있습니다.

Next.js가 처음 공개 되었을 때 6가지 원칙을 내세웠다.

1. 복잡한 설정 없이 사용하기 편하게 해줄께
2. JavaScript만으로 프론트엔드, 백엔드 다 하게 해줄께
3. 자동으로 코드스플리팃 해주고, 서버사이드렌더링 가능하게 해줄께
4. 다양하게 (언제, 어디서, 어떻게, 얼마나) data-fetching하게 해줄께
5. 요청사항을 예상 가능하게 해줄께
6. 배포 쉽게 하게 해줄께

 

 

근데 Next.js는 왜 나온거야?

React는 Client Side Rendering을 제공하는데 CSR의 단점을 보완하기 위해 등장했다.

• FCP(First Contentful Paint) ( 초기 화면이 보이는 시간 )이 길어
• 보안에 취약해( 클라이언트단에서 파일들을 가지고 있어야하니까 )
• CDN ( Content Delivery Network ) 캐쉬가 안돼 
• SEO 안좋아 ( 처음에 빈 HTML이니까 )
• 자바스크립트가 필수야 ( 사용자가 브라우저에서 자바스크립트를 비활성화하면 아무것도 못해 )

 

그래서 Next.js는 SSG ( Static Site Generation )을 제공해.

SSG는 빌드할 때 렌더링을 해. 그래서 처음 브라우저가 서버에서 요청했을 때 CSR처럼 빈 HTML 파일이 오는게 아니라 

이미 필요한 데이터들, 화면을 다 그린 HTML을 응답받아. 그러면 당연히

• 처음에 자바스크립트 파일 등 다른 파일들을 다운로드 받을 필요가 없으니까 초기 로딩 속도가 빨라.
• 보안에 좋아 ( 클라이언트 단에서 다운로드 받을 파일들이 없고 그 파일들은 서버에 있으니까)
• CDN에 캐쉬가 되어서 나중에 다시 요청해도 빠르게 응답받을 수 있어
• SEO에 좋지 ( 빌드할 때 그려서 브라우저가 요청할 때는 이미 화면이 다 그러져 있으니까 )
• 자바스크립트 없어도 빌드할 때 다 그리니까 화면이 보여

 

근데 빌드할 때 렌더링이 되니까 데이터들이 정적이고, 모든 사용자에게 동일한 내용을 보여줘야하는 단점이 있어.

 

그러면 최신화 된 데이터들을 받을려면 어떻게 해야할까? 최신 데이터로 페이지를 다시 만들어야겠지?

그래서 ISR ( Incremental Static Regeneration )이란 것도 존재해.

주기를 정해서 페이지를 다시 생성하는 거지.

그래도 문제야. 실시간 데이터가 아니고 사용자 별로 다양한 데이터를 보여줄 수 없어. 주기를 실시간 수준으로 하게 되면 아무래도 서버에 무리가 많이 가겠지.

 

그래서 나온게 SSR ( Server Side Rendering )이야.

SSR은 빌드 시에 HTML파일을 만들 지 않고, 클라이언트에서 요청할 때 HTML을 만들어서 보내주는거야.

• 최신의 데이터를 보여줘 ( 요청할 때 만들기 때문에 )
• 사용자마다 다른 데이터를 보여줄 수 있어 ( 요청한 사람이 누군 지 알기 때문에 )

 

 

근데 또 이러한 장점 때문에 문제가 생겨

• SSG, ISR보다 비교적으로 느려 ( 요청할 때 만드니까 )
• 서버에 과부하가 일어날 수 있어 ( 요청할 때 만드는데 서버에 요청이 많아지면 )
• CDN 캐싱이 안돼 ( 요청할 때마다 새로 만드니까 )

 

Next.js는 이러한 렌더링 방식들을 섞어서 할 수 있어.

페이지 특징에 맞기 필요한 렌더링 방식을 사용하면 앱 성능이 너무 좋아지겠는데?

근데 어떻게 가능한거야??

 

Next는 사용자에게 빠르게 화면을 보여주기위해 정적인 HTML을 pre-rendering해서 보여줘.

이 정적인 HTML은 Javascript 코드가 없기 때문에 사용자의 인터랙션이 불가능 해.

그래서 클라이언트는 정적인 HTML 파일을 먼저 받고, 리액트 코드나 자바스크립트 코드를 나중에 받아서 이미 받은 HTML안의 DOM 요소들 위에 다시 렌더링이 되면서 자바스크립트 코드가 입혀지는거야. 그럼 동적인 웹으로 바뀌겠지.

이걸 하이드레이션 ( Hydration ) ( 수화 )이라고 해.

다시 클라이언트단에서 렌더링하면 성능이 더 안좋은거 아니냐고 하지만, DOM 요소에 찾아 들어갈 뿐 다시 repaint는 하지 않는다고 해. 

 

폰트 등을 자바스크립트 파일로 받아오게 되면 처음 화면 이후 받아온 폰트로 변경되는 모습이 보이는 문제가 생기기도 해.

그렇기 때문에 Pre-rendering된 화면과 하이드레이션 된 화면의 간극을 줄이는 것이 중요해 보여.

 

렌더링 특징에 맞게 페이지에 적용시켜서 성능 좋은 앱을 만들자!