next.js의 특징

Next.js는 리액트 기반의 프레임워크다.

• 실제 프로젝트에서 프레임워크가 가지는 장점이라면 커뮤니케이션시간이 감소된다는 점이다.
• 리액트는 라이브러리이기 때문에 자유도가 비교적 높다. 그 말은 개발자 마다 옳다고 생각하는 바가 다를 수 있고, 협업 할때 논의해야할 지점이 늘어난다는 얘기이기도 하다..(ex- "그 디렉토리 구조 별론데..")
• 반면 프레임 워크는 사용방법이 정해져있기 때문에 위에서 말한 "그 디렉토리 구조 별론데.."에 관한 논쟁을 할 필요가 없다는 말이다. 공식문서에서 사용하라는 대로 쓰면 된다.

Next.js는 서버사이드 랜더링을 지원한다.

• SSR을 쓰면서 얻는 이점이 무엇이 있을까? 처리성능과 네트워크 관점에서 이득을 볼 수 있다.

1. 처리성능

CSR의 경우 사용자의 브라우저에서 Javascript 파일을 실행한다. 사용자의 개인 기기가 아무리 좋다고 하더라도 서버보다는 성능이 좋을 순없을 것이다. 처리의 주체를 서버로 넘김으로써 속도의 이점을 가져올 수 있다.

2. 네트워크

CSR 방식

SSR 방식

CSR과 SSR방식에서 요청과 응답이 전달되어야하는 차이를 살펴보면 CSR방식에서 3,4번 과정이 더 필요하다는 점이다.

단, 2단계가 추가되어 보여 큰 차이가 없다고 생각될 수 있지만, 사실 하나의 요청을 보내기위해서는 거쳐야하는 단계가 많다.

CSR을 사용할때 외부통신이 이루어지려면 다음과 같은 과정들을 거쳐야 한다..

client -> router -> 모뎀 -> ISP ... -> ISP -> LB -> Firewall -> server로 GET 요청 도착

MAC에서는 traceroute www.naver.com 명령어를 터미널에 입력하면, 네트워크 처리과정을 볼 수 있다.

만약 SSR방식을 사용하면서 frontend server와 backendend server가 내부통신을 사용한다면 해당 단계는 훨씬 줄어들게 된다.

SSR은 장점만 있을까? 아니다

장점

• SEO 최적화
• 저사양기기 지원
• API 은닉화
• 브라우저의 호환성 향상
• FCP 성능 향상

단점

• 서버비용 증가
• 개발 복잡도 증가
• 응답시간 증가
• 서버 의존도 증가
• 페이지 전환 성능 감소

React18 동시성

React18버전의 공식 문서를 보면 동시성(Concurrency)를 제공하기위해 노력했다는 점이 특징적이다.

next.js얘기를 하다 왜 갑자기 react18 버전의 동시성얘기를 하냐하면,
React18버전의 새로운 기능인 React Server Component를 Next.js에서도 지원하게 되면서 많은 변화가 일어났기 때문이다.

잠시 돌아가서 SSR의 장점 중 하나로 빠른 FCP를 언급했는데 이를 풀어서 설명하면 다음과 같다.

CSR에서 Js파일이 로드👉 데이터 패칭 👉 컴포넌트가 랜더링 된 이후에야 완전한 화면을 보여준다.
SSR
에서는 서버에서 데이터 패칭이 일어나고 👉 완성된 HTML을 만든다. 일단 상호작용할 수는 없지만 뭐라도 채워진 HTML을 사용자에게 보다 빨리 보여주어 UX를 개선하고자 한 점이다.

다만, 실제 사용자와 상호작용이 이루어지려면 JS가 모두 로딩되고 Hydration이 되어야하기 때문에 TTI시간이 지연된다는 단점이 있다.

React18이전 SSR의 한계

1. 모든 Fetching이 완료되기 전가지는 어떤 것도 보여줄 수 없다.

예를들어 위와 같은 네이버와 같은 홈페이지에 접속한다고 해보자.

간략하게 구역을 나누면 위사진처럼 SearchBar, User, TopBanner, News, SideBanner로 나눌 수 있을 것이다.
13버전의 Next.js에서 SSR방식을 사용하여 해당 페이지를 로드한다고 가정해보자.
그런데 만약 News데이터를 가져오는 과정에서 용량이 큰 JavaScript파일이 있거나, API응답이 오래걸리는 문제가 발생한다면 어떻게 될까?

아마 해당 페이지를 보여주는 main.html을 만들기 위해 상당히 오랜 시간이 걸릴 것이다.왜냐하면
Data fetching과정에서 하나라도 완료되지 않으면 HTML을 만들 수 없기 때문이다.

그러면 News만 초기랜더링에서 빼면 안되나?

불가능한것은 아니지만 만약 뉴스피드가 우리 사이트의 핵심 내용이라면 초기랜더링에서 제외할 수 없을 것이다.
(SEO에 영향을 준다던지, 중요한 핵심 비즈니스 라던지..)

2. 모든 JS가 로드되기 전에는 Hydrate할 수 없다.

즉, 페이지 구성에 필요한 모든 JavaScript 번들 파일이 다 다운로드 되어야 hydration 과정이 진행될 수 있다.

그럼 react18에서의 어떤 기능과 변경점이 위의 문제를 해결했을까?

next13이전버전의 페이지 라우터에서는 위의 과정이 순차적으로 진행되어야 하며, 이를 페이지 단위로 SSR을 했다면

리액트 18버전에서 도입된 streaming HTML, Suspense로 인해 해당 과정을 컴포넌트 별로 나눠서 진행할 수 있도록 변경된 것이다.

React Server Component

용어를 잠깐 정리하고 넘어가자면
Server Side Rendering / Client Side Rendering은 렌더링을 어디서 진행할 것인지에 대한 패러다임 혹은 방법론을 의미한다.
React Server Component는 ssr을 구현하는 방법중하나로, React 18v부터 새롭게 추가된, 새로운 유형의 컴포넌트이다.

React Server Component 이하 RSC

• 서버측에서만 실행되는 컴포넌트로 브라우저에서 실행되지 않는다. ( 애초에 번들파일이 전달되지 않아서 브라우저에서는 저런 컴포넌트가 있는지도 모른다.)
• 상호작용이 없어서 hydration이 필요없는 컴포넌트
• 장점 : 번들에 서버컴포넌트가 포함되지 않으므로 번들용량이 감소됨.
• 단점 : client측 기능과 이벤트 핸들러 사용이 불가능하다.(당연함), 직렬화된 값만 props로 전달 가능하다.

직렬화: 객체, 배열, 클래스 등의 복잡한 구조의 데이터를 네트워크상으로 전송하기 위해 아주 단순한 형태(문자열, Byte)로 반환하는 것.

Javascript의 함수는 클로저, 렉시컬 스코프 환경에 의존하기 때문에 직렬화 될수 없다. 따라서 RSC에서는 props로 javascript 함수를 전달할 수 없다.

Next.js 13 버전부터 React의 Suspense의 기능과 함께 사용하게 되면 페이지의 모든 정보가 패칭되어야 html이 전달되던 문제를 해결할 수 있다.

스트리밍 : 서버에서 클라이언트에게 전해줘야 하는 데이터가 크거나, 준비하는데 오랜 시간이 걸릴때 데이터를 작은 조각으로 나누어 (마치 강물에 떠내려가는것 처럼) 연속적으로 응답하는 것

회고 및 정리

이번 프리온보딩 강의는 기존 알고 있던 지식에 왜?를 붙이며 이유를 찾아가는 강의였다.

Next.js가 서버를 가지고 있다는 것의 장점과 단점은 무엇인지, 13버전의 변경사항이 기존의 SSR의 어떤 점을 개선하고자 하였는지 확실히 이해할 수 있었다.