SCR & SSR
CSR: Client Side Rendering
SSR: Server Side Rendering
이런 식으로 요청하는 것의 특징은 화면이 새로고침 된다는 것이다.
그러면 복잡한 웹 사이트에서 a를 요청했는데 a의 내용이 많으면 용량도 증가되고 느려진다.
SPA
AJAX 요청(비동기 데이터 통신):
처음엔 아무것도 없는 껍데기만 받아오고, 필요한 것들을 모두 api로 서버에 요청하는 방식이다. 데이터를 받아와서 클라이언트가 렌더링한다.
요즘에는 fetch api를 써서 구현한다.
CSR
CSR의 방식이다. 여기서 분홍색 네모박스의 과정까지 가도 첫페이지가 아직 렌더링되지 않는다.
SSR
안 되겠다. 첫 페이지만 서버에서 만들자
SSR의 기술은 CSR과 똑같다. 다만 첫페이지가 빨리 보인다는 차이가 있다.
리액트도 이처럼 rederToString() 같은 함수들로 서버에서 리액트 코드로 html을 만드는 방법들을 제공한다.
클라이언트에서는 리액트같은 경우 하이드레이트라는 기술로 서버에서 주는 html에다 이벤트를 등록하는 일을 해야한다.
이 때 하이드레이트라는 함수로 처리할 수 있다.
이제 모든 문제는 해결된 것일까?
1. 컴포넌트에서 서버 api 요청을 해야하는 상황들..
2. 여전히 큰 번들 사이즈로 빠른 인터랙션 제공 어려움
-
api 요청 자체를 줄일 수는 없을까?
-> 멀티페이지로의 회귀 -
번들 사이즈를 좀 더 줄일 수 없을까?
-> 리액트는 이미 몬스터
리액트 팀의 답
서버사이드에서 리액트 렌더링을 하자.
리액트 서버 컴포넌트(RSC)
클라이언트 컴포넌트랑 서버 컴포넌트로 나눠져 있고, 이것들이 하나의 트리로 동작
- 요청을 하면 서버는 리액트에서 직접적으로 db에 접근해서 데이터를 가져온다.(리액트 코드 내에서 일어나는 일)
- 데이터로 리액트 렌더링 작업을 한다.
- 결과를 json 형태로 준다.
- 리액트가 렌더링 작업을 한다. 리액트 내부에 컴포넌트 트리를 만든다.
RSC의 특징
- 서버는 렌더링 결과만 전달, 번들링된 코드가 전처럼 크지 않고 따라서 용량 감소
- 렌더링된 결과는 점진적으로 streaming 으로 전달
- 양쪽에서 렌더링을 하지만 state 유지 가능
웹세상은 어떻게 바뀔까?
-
이제 서버환경도 리액트가 다 하는 것인가? No
기존 백엔드에 리액트 연결을 위한 백엔드 라이브러리 필요(노드js 환경) -
SSR은 어떻게 되는가?
두 개는 다른 목적으로 탄생. 상호보환하거나 적절한 기술 선택 -
서버 환경을 구성해야 할 이유가 늘어남
백엔드 운영의 어려움이 가속화될 수 있음
RSC 가술을 활용해야 할 것 같은 부담감
fe & be 개발자의 역할?
각각의 용도
참고자료
