next.js와 리액트

next.js는 리액트의 프레임워크!

 그렇다면 리액트는? 라이브러리(UI, 상태관리, 라우팅 등에 대한)

 그럼 먼저 프레임워크와 라이브러리의 차이에 대해서 알아봐야겠군!

프레임워크와 라이브러리의 가장 큰 차이는 제어 흐름의 소유권을 누가 갖고 있는지!
 즉, 개발자가 제어 흐름의 소유권을 갖고 단지 도구로 가져다 쓰는 것이라면 라이브러리, 개발에 대한 구조와 규칙이 제공되어서 개발자가 그것에 맞춰서 코드를 작성해야한다면 프레임워크라고 할 수 있다. 두 개의 개념을 찾다보면 철근뼈대가 잡혀있는 건물안에서 건물을 짓고 있는 그림과 망치를 들고 있는 그림을 자주보는데 이처럼 구조가 잡혀서 그 안에서 작업을 하는 것을 프레임워크라고 생각하면 되고, 망치처럼 필요할 때 꺼내서 사용할 수 있는 것을 라이브러리라고 생각하면 된다.

 그런데, 리액트도 규칙이 있어서 jsx문에 대한 것이나 훅에 대한 것들 등 리액트가 규정해놓은 규칙이 있지 않냐? 라고 물어볼 수 있는데 라이브러리를 사용하는 사용방법에 해당하는 것이지 '앱이 생성되는 방식이나 라우팅되는 방식들에 대해서 개발자가 얼마든지 제어 흐름을 컨트롤 할 수 있다는 점을 보았을 때에 리액트는 프레임워크보다 라이브러리에 가깝다.'라고 생각할 수 있다.

 실제로 과거 리액트 팀에서 리액트의 모든 기능을 잘 활용 위해서 next.js 프레임워크를 사용하는 것을 언급한 적이 있고, 공식문서에 가보면 리액트는 라이브러리라고 소개되는 것을 확인할 수 있다.

그렇다면 우리는 왜 next.js를 사용함으로써 리액트를 좀 더 잘, 제대로 활용한다고 할 수 있을까?

1. 리액트로 인한 CSR의 단점을 해결 >> 하이브리드 웹 앱

CSR : 렌더링 하는 주체자가 클라이언트
 초기 로딩 이후에 빠른 UX를 제공할 수 있으나, 반대로 초기 로딩 시간이 오래 걸리고 서버에서 처음 넘어온 HTML에는 body가 텅텅 빈 상태로 오기 때문에 자바스크립트 활성화가 필수적이고, SEO 최적화가 어렵다. 또한 모든 렌더링 작업이 클라이언트단에서 이루어지기 때문에 보안에 취약하다. 또, CDN에 캐시가 되지 않는다.

SSG : 렌더링 주체가 서버, 서버에서 빌드할때 렌더링
 정적인 사이트에 대해서 서버에서 빌드할 때 렌더링해서 요청이 있을 때 모든 요소가 렌더링 된 페이지를 제공함. 이로 인해 페이지 로딩 시간이 빠른 장점이 있고 자바스크립트가 이미 활성화되어 옴으로써 자바스크립트가 필요없고 SEO가 최적화된다. 또한 보안이 뛰어나고 CDN에 캐싱이 되어진다. 하지만, 데이터가 정적이어야 한다는 단점이 있다.

ISR : 렌더링 주체가 서버, 주기적으로 렌더링
 SSG의 장점을 가지고 있으면서 데이터가 주기적으로 업데이트가 되도록 설정한 것. 하지만, 실시간 데이터는 아니라는 점과 사용자별 데이터를 제공할 수 없다는 점은 여전히 단점으로 갖고 있다.

SSR : 렌더링 주체가 서버, 요청시 렌더링
 SSG와 다른 점은 요청시 렌더링이 되기 때문에 실시간 데이터가 보장되는 반면 CDN에 캐싱되지 않는 점과 SSG, ISR보다 비교적 느릴 수 있고 매번 서버에서 렌더링이 일어나야하기 때문에 서버에 과부하가 걸릴 수 있다는 단점이 있다.

하이브리드 형태를 통한 성능 좋은 웹 앱 제공
페이지 별로 각각의 페이지에 따른 적합한 렌더링 방식을 선택함으로써 각 페이지의 목적에 부합하도록 개발

어떤 페이지에 어떤 방식을 사용할까?
1. 사용자의 로그인이 필요 없음 && 데이터 변경이 없음 >> SSG
2. 사용자의 로그인이 필요 없음 && 데이터가 종종 변경이 있음 >> ISR
3. 사용자의 로그인이 필요 없음 && 데이터가 자주 변경이 있음 >> SSR / Hybrid
4. 사용자의 로그인이 필요 >> CSR / SSR / Hybrid

2. 하이드레이션

 먼저 정적 HTML을 통해 동작하지 않지만 사용자에게 제공할 수 있는 정적인 페이지를 제공하고 react와 js를 통해 컴포넌트 렌더링을 통해 페이지가 기능을 갖도록 동작(Pre-rendering)

참고)) TTV(Time To View)와 TTI(Time To Interact)에 대하여
 사용자에게 스켈레톤 UI를 제공함으로써 기능은 아직이지만 패칭되는 동안에 사용자가 로딩중이네? 라는 생각을 할 수 있도록 정적인 페이지를 제공하는 것은 사용자가 요청에 대해서 반응하고 있다는 것을 제공함과 동시에 TTV에서 TTI까지의 간극에서 발생할 수 있는 사용자의 불편을 해소할 수 있다.

넥스트가 처음 만들어질때 제시한 6가지 원칙

1. 별도의 설정 없이 프레임워크 사용이 가능
2. 자바스크립트만으로 프론트엔드와 백엔드를!
3. 자동으로 코드 스플리팅과 서버 렌더링을 제공
4. 데이터 패칭을 설정 가능하도록
5. 요청사항을 예상 가능하도록
6. 배포가 손쉽게 되도록