SSR

• nextjs는 React로 만드는 SSR(서버사이드렌더링) 프레임워크이다.
• nextjs는 pages라는 폴더에 잇는 파일을 기준으로 해당 파일명을 도메인명으로 사용한다. 즉, pages 폴더에 pages1.tsx 라는 파일을 추가하면 localhost:3000/page1 처럼 자동으로 라우팅설정이 된다.
  public폴더도 pages 폴더와 동일하게 라우팅을 할 수 있지만, public 폴더는 모든 사람이 public에 접근할 수 있기 때문애 public 폴더를 이용하는 라우팅은 사용하지 않는 것이 좋다.

const Heading = (props) => {
  const variable = 'red';
  
  return (
    <div className='title'>
    	<h1> {props.heading} </h1>
		<style jsx>
          {`h1 {
			color: ${variable}
		  }`}
        </style>
    </div>
  )
}

NextJs는 ReactJs의 SEO문제를 해결하고자 등장했다.

• 대표적인 CloudServiceRandering(CSR) 라이브러리인 ReactJS는 Request에 대해 JavaScript 코드만을 Response하는데, 이 JS코드가 최종적인 HTML을 만드는 구조라서, JS를 돌릴줄 모르는 검색엔진이 사이트를 크롤링하면 텅 빈 HTML만 인식하게 되어 검색친화적이지 못하다.
• 반면, NextJS는 Request가 오면, 서버측에서 먼저 Rendering을 거친 후 HTML과 JS를 따로 Reponse한다. 따라서 사용자는 HTML코드를 먼저 받아보게 되고, 그 이후 상호작용에 필요한 JS코드를 받아오기 때문에 사용자 측에서 느린 네트워크 혹은 네트워크끊김, 모종의 이유로 인한 JS의 미 실행 등의 환경에서도 대략적인 페이지의 내용을 마주할 수 있다. 이는 사용자 경험에서 큰 차이이다. 또한, HTML 코드를 검색엔진이 바로 받아 볼 수 있기에 관련 키워드 검색시 사이트가 검색결과에 노출될 가능성이 커진다.

NextJS 기초문법

1. 시작하기
* npx create-next-app --typescript

2. Pages 폴더
* Page에 들어있는 파일명으로 라우터가 생성된다. 즉, Pages폴더 안에 Hello 라는 이름의 파일이 존재한다면, 해당 웹앱은 '/hello'라우터를 갖게 된다. 또한, NextJS는 그 파일 안에 들어 있는 컴포넌트를 작동시킨다.

3. Link
* ReactJS는 react-router-dom으로부터 Link를 가져와서 <a>를 대신하여 사용하지만, NextJS의 경우에는 next/link 로부터 Link를 가져와 Link 컴포넌트 안에 <a>태그를 작성하여 사용한다.
* 즉, ReactJS는 anchor 태그를 대체하여 링크컴포넌트를 쓰지만, NextJS는 링크컴포넌트 안에 a태그를 사용한다. 
→ 이 차이는 : 해당 컴포넌트의 속성을 지정해 줄 때 큰 차이가 생긴다. React의 경우 Link태그 안에 className 등의 속성을 지정해주지만, Next는 anchor태그 안에 className 등의 속성을 지정해줘야 한다.

Rendering

* 웹개발에서 보통 랜더링이란, HTML 코드를 웹 브라우저가 읽어들여서 브라우저 상에 보여주는 행위를 말한다.
* 따라서 CSR은 웹 브라우저가 읽어들일 HTML 코드를 Client 측에서 보내준다는 것이고,
* SSR은 Server 측에서 보내준다는 뜻이다.
* Client 측에서 보내준다는 것은 : Client의 행동에 따라 interactive 하게 HTML 코드가 반응하는 경우를 의미한다.
* HTML 코드가 반응한다/가변적이다 라는 점은 : "JavaScript를 이용해서 HTML 코드를 만들어 내는 방식" 이라는 점을 논리적으로 함축한다.
* 즉, JS로 HTML 코드를 짜는 Front-End 라이브러리/프레임워크들이 대부분 CSR 방식이다. React, Vue 등... : 이런 웹 어플리케이션을 SPA(Single Page Application)라고 한다.

HTTP메시지(1),(2)

• HTTP 메시지는 요청Request과 응답Response 두가지 타입이 존재하며 각각 특정한 포맷을 가지고 있다.
• Request : 클라이언트에 의해 전송되는 메시지를 요청(Request)이라고 한다.
  

1. Start-line : HTTP 요청/ 또는 요청에 대한 성공 또는 실패가 기록되고 항상 한줄로 끝난다.
2. HTTP Headers : 시작줄 다음으로 요청에 대한 설명/ 또는 메시지 본문에 대한 설명이 들어간다.
3. Empty Line : 요청에 대한 모든 메타정보가 전송되었음을 알리는 빈 줄이 삽입된다. (헤드와 본문 사이)
4. Body(본문, optional) : 요청과 관련 된 데이터(HTML form 콘텐츠 등)/ 또는 응답과 관련 된 문서(document)가 선택적으로 들어간다. 본문의 존재와 크기는 시작줄 및 HTTP헤어에 명시된다.
   → HTTP메시지의 시작줄과 HTTP헤더를 묶어 요청헤드라고 부르며, 이와 반대로 HTTP메시지의 페이로드='본문(body)'

👉🏻 출 처

SPA

- CSR은 최초의 웹 접속시, 랜더링에 필요한 모든 HTML코드를 Server로부터 받아와야만 한다. 그러고 나면 그 이후부터는 Client의 행동에 따라 JS코드가 반응하면서 HTML코드가 생성/변경/삭제되고 이를 통해 웹페이지가 UX측면에서 interactive하게 반응하게 되는 원리이다.
- 따라서, CSR 방식에서는 최초의 웹 접속이 이루어지고 나면 더이상 HTML 코드 변경을 위한 Request 없이도 화면의 변경이 가능하다. 이미 필요한 HTML 코드가 JS를 통해 전부 다운 받아져 있으니까...!! 이는 곧, → Server 로부터 자유롭다는 뜻이고, Request와 이를 바탕으로한 새로고침(새로운 화면) 없이 한 화면 상에서 기능수행이 이루어진다는 뜻이므로 우리는 CSR 방식의 웹어플리케이션을 SPA이라고 부르는 것이다. ("단일 페이지로 이루어진 어플리케이션!!!")
- 물론, 엄밀히 말하자면 SPA는 어플리케이션의 종류를 지칭하는 용어이고 CSR은 렌더링방식을 지칭하는 용어이긴하다 (* SPA 의 반대말 : MPA MultiPageApplication)
- SSR은 CSR의 반대라고 보면 된다. 당연히 SSR방식의 웹어플리케이션은 MPA라고 불릴 것이며, Rendering이 필요할 떄마다 Server로부터 정해진 HTML코드를 받아오게 된다. 이런 점에서 interactive한 UX를 제공하기는 어렵다. 대표적으로는 PHP, pug, jsp 등이 있다. 소위 말하는 '템플릿엔진'이 SSR 방식이다.
- 하지만, 최초의 웹 접속시 Server로부터 받아와야하는 데이터의 양이 CSR에 비해서 적다는 특징이 있다. SSR은 현재 필요한 코드만 딱 받아오지만 CSR은 JS를 통해 모든 HTML코드를 받아오기 때문이다. 그래서 SSR은 최초 접속시 웹로딩이 빠른반면, CSR은 SSR에 비해 느리다.
- 동시에, 바로 이러한 점 때문에 SSR은 서버측 부담이 가중된다. 랜더링 때마다 서버가 Request를 받아 Response 해줘야 하기 때문이다. 반면, CSR은 Data를 주고 받는 POST요청 위주로 트래픽이 발생한다는 점에서 서버부담이 적다.
- SEO (Search Engine Optimization) 측면에서 볼 때는 SSR이 유리하다. SSR은 HTML코드를 서버로부터 직접 받아오기 때문에 검색엔진의 봇이 크롤링 할 때 보다 정확하고 많은 정보를 가져갈 수 있다. 반면, CSR은 원칙적으로 빈 HTML코드를 받아가기 때문에 검색엔진에 덜 친화적이다.
- Facebook에서 React를 만들어서인지 이런 단점을 극복하기 위해 만든게 <meta />태그이긴하다. 
- 그래서, CSR방식으로 웹App을 만든다면, <meta/>태그를 좀 더 신경써야한다.
- 다만, 현재에 들어서는 CSR이든 SSR이든 가리지 않고 meta태그를 관리하는게 최근의 트랜드 이기도 하고, 각종 검색엔진 봇에서도 meta태그 친화적인 태도를 보이고 있기 때문에 SEO 때문에 CSR을 주저할 필요는 없다.

👉🏻 출 처