1.NEXT JS

1. SSR 에 대해서

1.1 SSR vs CSR

	CSR(Client Side Rendering)	SSR(Server Side Rendering)
대표적인 예	React.js	Next.js
장점	서버와 클라이언트 간의 데이터 양과 트래픽 현저히 감소 단 한번의 랜더링만 있으므로, 페이지 이동이 빠름 업데이트시 중복되는 화면은 그대로 두고 업데이트 되는 화면만 바뀜(SPA)	초기 랜더링 속도가 빠름 SEO 사용가능
단점	SEO사용 불가 코드 Spliting으로 초기 랜더링이 느림	간단한 데이터 수정도 서버를 거쳐야함 연속적인 랜더링을 할 경우 서버 비용 증가 및 과부화로 서버가 터질수 있음테스트

1.2 SSR vs CCS Rendering 랜더링 차이점

	CSR(Client Side Rendering)	SSR(Server Side Rendering)
랜더링	CSR은 SPA(Single Page Application)로, 클라이언트 사이드에서 HTML을 반환한 후에 JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행하는 것이다. 유저의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 SSR보다 빠른 인터랙션이 가능합니다. 단, 페이지를 읽고 자바스크립트를 읽고나서 화면을 그리기 때문에 초기구동 속도가 느립니다.	SSR은 사용자가 웹페이지에 접근할 때, 서버에 각각의 페이지에 대한 요청을 하여 HTML,JS 등을 다시 다운로드 하여 화면에 렌더링하는 방식이다. CSR과 비교하여 초기 구동속도가 빠르다는 장점이 있지만, 모든 요청에 관해 필요한 부분만 렌더링하는 것이 아니라 전체 페이지를 렌더링하기 때문에 불필요한 작업이 발생한다.

1.3 SSR 과 CSS의 랜더링 동작 방식

1.3 왜? SSR이 검색엔진(SEO)에 최적화 일까?

네이버나, 구글이나, 다음 같은 곳에서 우리의 사이트를 검색했을때 우리의 사이트를 제대로 수집하기 위해서는 검색엔진에 최적화 되어야하는데, SSR이 검색엔진에 최적화라고 한다.

그 이유는 서버에서 클라이언트 대신 랜더링을 해주기 떄문이다.

클라이언트 대신 서버에서 랜더링 해주는게 왜 검색엔진에 최적화일까?

클라이언트에서 랜더링 하게 되면, 위에서 랜더링 방식에서 보듯이 빈 HTML을 반환후 -> JS 동작 -> 완성된 화면을 랜더링 하기 때문에 검색시 늦게 검색리스트에 뜰수 있다.

그러나 서버에서 랜더링을 하면, HTML을 다운로드 받고 바로 화면을 유저한테 바로 보여주기 때문에, 검색시 빠르게 검색리스트에 뜰수 있다.

1.4 SSR과 CSR로 본 REACT와 NEXT의 장 단점

1.5 그러면 언제 REACT를 사용하고 언제 NEXT를 사용할까?

REACT는 컴퓨터 성능보다 떨어지는 모바일 앱 만들때 사용하는것을 추천한다.

자사에서만 사용할 홈페이지 만들때는 어차피 검색 될 필요가 많이 없으므로 REACT를 사용한다.

구글이나 네이버 , 다음에서 검색되어야할 것들은 NEXT로 제작해야한다.

2. Next.JS

2.1 Next.JS란

• Next. js 는 모든 페이지에 pre-rendering을 해준다.

• pre-rendering이란, 사전에 미리 HTML 파일을 만들어 놓음

• Next.js의 pre-rendering에는 1. 정적생성,2.Server side rendering이 있다.

• 이 둘의 차이점은 HTML 파일이 언제 생성되는가 이다.

2.2 Pre-rendering의 종류

• 1.정적생성 (static generation)

프로젝트가 빌드(코드가 소프트웨어가 되는)가 되는 시점에 html 파일들이 생성한다.

모든 요청에 재사용

정적 생성된 페이지들은 CDN(Contents delivery networ)에 캐시되고 나중에 또 요청할때 캐시에 저장된것을 재사용하게 함

데이터를 받을 때 getStaticProps / getStaticPaths 를 사용하며, 이것을 사용해서 데이터를 가져오는 경우, HTML에 데이터가 적용된 상태로 pre-rendering 됨

• 2.SSR (Server Side Rendering)

매 요청마다 html을 생성

그렇기에 항상 최산 상태 유지

데이터를 받을 때 getServerSideProps 를 사용하며, 이것을 사용해서 데이터를 가져오는 경우, HTML에 데이터가 적용된 상태로 pre-rendering 됨

2.3 정적생성 되어야할 페이지 또는 SSR 되어야할 페이지

2.4 Pre-rendering이 사용 여부

• Pre-rendring이 사용 되지 않는다면

“빈화면 -> JS Load -> “페이지요소가 채워지고 사용자에게 보여짐”

• Pre-rendering이 사용 된다면

“사전에 만들어진 HTML(메타데이터 포함)” -> JS Load -> “페이지요소가 채워지고 사용자에게 보여짐”

2.6 getStaticPaths

• 1.특징

지정된 것들을 정적생성(static generation) 할수 있다.

(1) fallback false 일 경우 : 지정된것들은 정적생성하며 ,지정되지 않은것들은 없는걸로 판단, 클릭시 404 error 뜸

(2) fallback true 이면서 Link일경우 :

viewport에 있는 초기에 보여지는 화면 또는 스크롤시 viewport에 나타나는 것들을 prefetch한다.

prefetch란, 사전에 데이터들을 가져오는것을 의미한다. 따라서 정적생성한것처럼 나타난다.

tip ) 단 내가 scroll을 밑으로 빨리해서 클릭한 Link들은 클릭한것보다 정적생성이 늦게 되므로 (빈화면 -> jsLoad -> 데이터를 포함한 HTML)로써 나타나게 된다.

• 2.유용한점

특정인것들만 정적생성(static generation) 해줌으로써, 모든것들을 pre-rendering 해줬을 경우 걸리는 많은 빌드 시간을 줄일 수 있다.

따라서 최초의 접속자만 처음에 빈화면이 나오기 떄문에 불편할수 있지만 그 이후 접속자들은 재사용된것을 봄으로 느려지지 않는다.

• 3.사용방법

3 Link의 동적페이지

(동적페이지일때, Link의 as와 href)[https://nextjs.org/docs/tag/v9.5.2/api-reference/next/link#dynamic-routes]

4. production Mode(배포 모드) vs Dev Mode(개발모드)

• 배포 모드 (프로그램을 배포하기 위해 컴파일 하는 모드)

초기화 하지 않습니다.

같은 문자열 상수라도 서로 다른 공간에 할당됩니다.

디버깅정보를 삽입하지 않고 코드를 최적화하여 실행 파일 크기를 최대한 줄여줍니다.

속도나 크기면에서 월등히 유리합니다. (메모리 점유율로 낮아지고 실행도 빨라짐)

더 이상 현재버전에서 내결함성이나 문제점들을 발견할 수 없었을때 빌드하여 주는 모드입니다.

• 개발 모드 (컴파일시 들어가는 디버깅에 필요한 자질구리한 정보를 뺀 알짜 프로그램만 쏙 뽑아냄)

실행파일에 디버깅 정보를 삽입하여 언제든지 디버깅을 할 수 있도록 하며 Debug서브 폴더에 실행파일을 만들어줍니다.

디버깅정보가 들어가 있기때문에 실행파일 상태를 확인할 수 있습니다.

디버그에 필요한 정보들을 실행시 계속 체크함으로써 속도가 느립니다.

따라서 정적체크는 배포모드에서 해줘야함

• 디버그 빌드와 릴리즈 빌드에서 서로 실행 결과가 다른 경우?

특히 디버그 빌드에서는 괜찮은데 릴리즈 빌드에서만 오류가 발생하여 프로그램이 죽는 경우가 있는데

이런 경우는 대부분 메모리가 깨진 경우에 발생합니다. 두 모드에서 동적으로 메모리를 할당하면 힙 영역에

요청한 크기만큼 메모리를 할당 받게 되는데 그 초기값이 다릅니다.

• 릴리즈 모드와 디버깅모드의 차이점은?

디버깅 정보를 실행코드 안에 넣느냐 안 넣느냐가 차이점이 되겠지요.

즉, 디버거 모드로 컴파일하게되면 실행상태에서 추적할수 있는 정보가 실행파일 안에 들어가게 되므로 용량이 커지고, 릴리즈 모드의 경우 디버깅 정보없어 순수한 소스코드자체의 기능만 컴파일되어 실행파일로 만들어집니다.

5. Error

Next.js 에서는 404 Error에 대해서, 처리해주는 404페이지가 static 파일로 이미 만들어져있다. 500 Error 도 마찬가지

404에러는 클라이언트가 클라이언트가 서버와 통신할 수는 있지만 서버가 클라이언트가 요청한 바를 찾을 수 없다는 것을 가리키는 HTTP 표준 응답 코드이다.

500 에러는 서버에서 발생한 에러를 의미한다.

하지만 내가 404과 500에러 페이지를 커스터 마이징 할수도 있다.

5.1 Next.js 404 Error Customizing

next.jx 에서는 404 페이지를 static generation으로 제공해준다. 그 이유는 자주사용되는 404 에러 페이지를 요청시마다 서버에서 rendering한다면 당연히 비용이 증가하고 사용자들은 느리다는 느낌을 받기 때문이다.

페이지 폴더안에 404.js 파일을 만들어주고 customizing 하면 된다.(이미 정적으로 만들어진 파일이기 때문에 커스터마이징 해도 정적으로 제공)

404 error 페이지는 static으로 제공해주는게 훨씬 좋다.

5.2 Next.js 500 Error Customizing

500 에러는 발생여부는 Production Mode에서 확인해야한다.

404 에러와는 다르게 페이지폴더안에 _error.js 파일을 만든다.

이 페이지는 정적으로 최적화 되지는 않는다.

그 이유는 서버 에러페이지(500에러페이지)를 정적으로 제공하지 않는 이유가, 정적으로 제공할 경우 에러가 발생했을때 서버쪽으로 에러를 보내는 작업을 동반하는 경우가 많기 때문이다.(why 정적으로 제공할경우 서버쪽으로 에러를 보내는 작업이 많아질까?)