출처 : 양동준님유튜브메모
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년뒤는 또 모르겠다.
프론트의 변화과정도 너무 빠르고,
지금 이걸 제대로하는 사람도 드물고,
그래서 더 어려워지고있다.