SSR & CSR

dev.dave·2023년 8월 2일

개발지식

목록 보기
47/53

출처 : 양동준님유튜브메모

ssr

Nextjs

단점 :
계속 서버에서 다운로드 받아서 쓰고,
서버에서 생성해주고, 그걸 넘겨주고
이런 과정을 거치기 때문에,
서버관리 / 서버 터짐
(서버관리가 빡쎄다. 리소스가 많이 든다. 즉, 관리 비용이 커진다.)

페이지 넘어갈때 느리다.

해결점 :

===========================================================

crs

리액트 등등

장점:
csr은 서버관리는 따로 필요가없고,
파일 스토리지에서 다운받아서 쓰는거고,
클라우드 프론트에서 쓰는거기때문이다.
대신 비용은 든다.

단점:
SEO 가 안된다. (정적 페이지에 index.html 에 seo설정이나 크롤링봇이 긁어갈 자료가 없다.)

초기 로딩이 느리다.(js번들 사이즈가 크기 때매 느리다.)

해결점 :

초기 로딩이 느린것은,
리액트 공식문서에 보면 ,
code splitting 을 하라했다. 그래서 js 번들 사이즈를 줄이고, 속도가 20% 빨라졌다.
code splitting 을 해서 초기 로딩 속도를 줄였다. 다운로드 용량을 보면 알 수 있다.

리액트 SEO는
Algolia라는 걸 써서 해결했다.
(유료서비스)

리액트 쿼리는 쉬운데,
리액트쿼리를 많이 쓰다 보니까,
useEffect를 아예 안쓰는것 같더라고요,
원래 useEffect는 잘 쓰는데,

useEffect에 대해 잘 아셨으면 좋겠다.
캐싱은 언제 처리를 하냐,
expire time은 어느정도로 두느냐,
캐싱은 실시간 변경이 안되다보니까,
아무튼 그런 거에 깊게 아시면 좋고,

csr이 왜 생긴건가?
원래는
백엔드가 모든걸 다하고,
프론트는 인터렉션한 부분을 처리하는 역활이었는데,
백엔드가 처리하기에는 많으니,
프론트 측에서 처리하는 부분으로 나뉘면 더 효율적이다 해서,
csr 방법이 나오고, 점점 커지고
그래서 프론트엔지니어 쪽은 성장을 많이 했는데,

그래서,

백엔드는 지금
json을 만드는 형태로만 진행이 되었고,

프론트는 그 json을 받아서,
프론트 내에서 모든걸 처리하는 과정이 되어버렸다.
그래서, 프론트가 어렵다.

백엔드 로직과,
프론트 로직중
더 깊히 따지면 프론트가 더 어렵다.

프론트는 시퀀스 대로 동작하지 않는다.
그게 가장 큰 문제이다.

지금 형태의 백엔드는,
json을 만드는 과정,
캐싱 처리,
레디스,
대용량처리 카프카
이런거
하는데,
이런것들은 어느정도 논리적으로 움직인다.
이게 어떤 식으로 움직일지,
감이 잡히고, 논리적으로 설명이 되는데,

프론트는,
설명이 안된다.
왜그러냐면,
-캐싱처리는, 웹스토리지에 저장하는것도 있고,
-비동기 적으로 동작하고,
이게 가장 크다.
또 뭐,,

  • 컴포넌트 별로 이상하게 동작을 하고
    즉, 주기적으로 동작하는 컴포넌트들이 있고,
    컴포넌트들이 잘못 동작을 했을떄, 다른 컴포넌트들에 그대로 영햐을 미치기 때문에,
    프론트는 손대기가 어렵다.
    즉, 이 컴포넌트 고쳤더니, 다른컴포넌트에 역여져있는 부분이 있어서 영향을 주고, 이런식이다.
    이 리덕스 같은 거 덕지덕지 붙이게 되면서,
    리덕스 하나에 문제생긴거를, 수많은 컴포넌트가 그걸 가지고 역여있으면, 그컴포넌트가 다 에러가 나면,
    어디서 손대야할지 감이 안잡히고, 야근을 하고, 스트레스에 아주,,대환장 파티죠.

그래서, 리덕스보다,
어싱크,즉, 비동기적인거 때매 생겨난 문제점들을, 해결하기위해서,
리코일이 생겼고, 대체를 하기 시작했다.

그래서
프론트가 만들기가 더 어려운것 같다.
왜?
csr 쪽에 지금 너무 많은 영향력이 미치고 있으니까.

백엔드 개발자는,
csr에서 다 해결해라, 백엔드는 json만 만들어 줄테니까~! 대용량 처리 잘 되게 레디스에 캐싱처리 잘 해서 하고,
너희 프론트엔드 개발자들은,
이 json을 가지고, 웹 페이지 잘 동작하게 돌아가게 만들어라.

이렇게 되니까,

프론트에서 거의 모든 과정들이 생겨버리게 되고,

백엔드가 json을 조금 잘 못 설계를 해도,
그거 잘못 설계했으니까, 프론트에서 알아서 처리해라
라는 경우가 수도없이 많습니다.

백엔드가 설계를 잘못한경우에도 불구하고,
백을 바꾸기가 어려우니 프론트에서 처리해라는 이상한 상황들이 진짜 많이 생기죠,

이런게 쌓이면,
어느정도 되서 프론트에서도 손을 대지 못하는 상황들이 생깁니다.

그래서,,프론트가 어려운것 같다.

프론트로 워낙 많은것들이 집중되는 상황에서,

아 이건 프론트에서 처리하는거 아닌것같고 백쪽으로 넘기자 해서,
NEXTJS가 나오기 시작한거다.

csr과 ssr의 사이에서 적정선 타협선을 찾아가는 과정인것같다.

지금 프론트가 너무 비대해 졌다.

앞으로 5년뒤는 또 모르겠다.

프론트의 변화과정도 너무 빠르고,

지금 이걸 제대로하는 사람도 드물고,

그래서 더 어려워지고있다.

profile
🔥개인 메모 / 다른블로그 자료 참조 / 다른블로그 자료 퍼옴 (출처표기) /여기저기서 공부 했던 내용 개인메모 & 참고 / 개인 기록 용도 블로그 입니다.🔥

0개의 댓글