next.js : 리액트를 위한 웹 프레임워크 정리

next.js = 리액트를 위한 웹 프레임워크

 

1. 라이브리러리 & 프레임워크 구분 

* 라이브리러리 : 개발자가 필요한 기능을 선택적으로 사용 + 제어 흐름을 직접 관리

* 프레임워크 : 개발자는 프레임워크의 규칙을 따라 코드를 작성

 

2. next.js 특징 6가지

(1) 복잡한 설정 필요없이 쉽게 개발 가능 

(2) js로 백엔드 + 프론트엔드 가능

(3) 자동 코드스플리팅 + 서버사이드렌더링 가능

(4) 다양하게 data-fetching 가능

(5) 요청사항을 에상 가능하게!
(6) 배포는 쉽게 ( vercel에서 만들었기에 가능)

 

 

3. 주요렌더링 기법 4가지 

-> 면접때 많이 물어봄 (리액트에서만 가능한것. 리액트+넥스트 같이 가능한 것)

(1) CSR

-  Client Side Rendering

: 랜더링의 주체가 클라이언트(브라우저)  

: 순수 리액트 사용했을 때 100% (라이브러리 x) 

: (장점) 사용자와 상호작용이 빠르고 부드러움

=> 서버에 추가 요청 필요 없음 

=> 처음에 리액트 서버(localhost:3000) 에 요청은 index.html 요청 (이때 js 파일도 받음) 뭉탱이로 한번에get

: (단점) 처음 로딩 시간 길음 (Time To View)

: 검색엔진최적화 (seo)에 불리함

 

(2) SSG

- Static Site Generation 

: ★최초 빌드시에만 생성이 됨

: 서버에 페이지 렌더링해서 클라이언트에 html 전달 방식

: 빌드 후에는 변하지 않도록 만들어 놓기

: (장점) 첫 로딩시 TTV 가 매우 짧음 (이미 만들어져있으니깐 :: 서버에서 만들어서줌) + SEO에 유리함

--> 서버 사이드 랜더링의 일종임

: CDN (Content Delivery Network) 캐싱 가능 

: (단점) 정적인 데이터만 사용 가능

: 서버와의 통신에 의존하므로, 클라이언트 사이드 렌더링보다 상호 작용이 느림

: 실시간으로 업데이트가 어려움

 

 

(3) ISR

: Incremental Static Regeneration

: 정적 페이지를 먼저 보여주고, 필요에 따라 서버에서 페이지를 재생성

: CDN (Content Delivery Network) 캐싱 가능 

: (단점) 실시간 페이지 아님 / 데이터에 의존하여 화면을 그리는 경우 사용 불가

 

 

(4) SSR

: 빌드 시점에 모든 페이지를 미리 생성하여 서버 부하를 줄이는 방식

: SSG, ISR처럼 렌더링 주체가 서버!

:  클라이언트의 요청 시 렌더링

: (장점) SEO 최적화 좋음 / 실시간 데이터를 사용 / CDN 캐싱 불가  

: 빠른 로딩 속도(TTV)와 높은 보안성을 제공

: (단점) 요청할 때 마다 페이지를 만들어야 함 / 서버 과부하

 

4. Hydration

: 수화작용 => 수분이 몸에 채워지는 느낌

: 완벽한 렌더링 방식은 없어서 혼합해서 사용함 = Hybrid =>가능하게 해주는 것이 Hydration

: 정적인걸 가져와서 리액트를 채운다

 

 

끝.