CSR_SSR

SPA의 등장 배경✨

기본적으로 웹은 client와 server로 나위어져 있는데 client는 요청을 보내는 역할.
서버는 요청을 보고, 이 요청에 대해 어떤 정보를 응답해줘야 할지 판단하고, 알맞은 html 문서를 내려준다.
그럼 client는 그 응답(html 문서)을 바탕으로 DOM에 그린다.
요청을 보내고 -> 응답을 받고 -> 그리고의 과정을 반복하는 것!
(DOM을 그리면서 css처리 + javascript를 로드)

그러다가 웹의 성능이 계속 좋아지고 내려줘야하는 정보의 양이 많아지게 되었다.
자바스크립트의 등장 이후로 사용자와의 인터랙션도 늘어나는 것.
(static한 정보만을 보여주는 웹의 초기 역할을 넘어섬)
그러면 요청, 응답 과정이 계속 많아질 것.

그러다보니 서버입장에서도 수많은 요청을 처리하다보니 서버부하가 커지게 되고,
사용자 입장에서도 계속해서 페이지 깜빡임이 발생하게 되었다(서버에서 html을 새로 받아 그리기 때문)
그 때쯤에 Ajax라는 기술이 등장하게 된다.

유저가 사이트를 쭉 보고 있다가 어떤 인터랙션이 일어나면 일부분만 정보를 다르게 표현해주고 싶어
html은 그대로 두고 특정 부분에 대한 정보만 바꾸자는 컨셉이 생겨난 것이다!!

SPA의 등장, CSR의 원리✨

개발자들은 여기서 만족하지않고 SPA라는 개념을 또 가져오게 되었다.
url을 움직이더라도 html을 다시 내려주고 싶지 않은 것!
그리고 익히 알고있는 리액트라는 자바스크립트 라이브러리는 SPA를 만드는 것을 지원한다.
그리고 SPA를 만드는 것을 지원하는 리액트는 클라이언트 사이드 렌더링 방식으로 동작한다.

보통 화면을 그리는 것은 서버에서 받은 html을 바탕으로 Client가 화면을 그리는데,
클라이언트 사이드 렌더링은 서버에서 받는게 아니라 그냥 클라이언트에서 알아서 화면을 그린다!
브라우저의 개발자 도구 - 네트워크 탭을 확인하면 url을 요청하면 서버에서 응답을 보내는 것을 확인할 수 있다.
server가 응답하는 html을 확인할 수 있는데, 리액트 프로젝트에서 이를 확인하면 서버에서 보내주는 html은 비어있다!

리액트에서는 빌드를 할 떄 내가 짠 모든 리액트 코드를 하나의 자바스크립트 파일로 만들어주는데 (babel로 transpiling, webpack으로 bundling) 사용자가 처음 사이트에 들어왔을때 server는 비어있는 html을 응답해버리고 클라이언트에서 bundle.js를 읽는다.
이 번들링된 파일을 읽고, DOM 화면을 그려주게 되는 것!

리액트 프로젝트에서 라우팅 처리된 nav 항목을 클릭할때마다 url이 변경되는 것을 볼 수 있는데
server는 새로운 html을 반환하지 않는다. 대신 client에서 변경된 url에 맞는 코드를 bundle.js에서 찾아 그린다.