nextjs가 데이터 절약을 위해 자동으로 압축되서 sse나 웹소켓 사용이 힘들긴 하더라구요 해결법 찾아보면 보통 사용자 node js를 따로 제작해서 소켓전용으로 하라던데 사실 데이터 전송이나 소켓 연결할때 헤더에 압축안함 옵션 박아주면 되긴합니다... 그 외에도 기존 장고나 스프링에 비해 부족한점이 많지만 만족도는 아직 높습니다. 간결하고 다루기 쉬우니깐요 굿굿 파이썬이랑 js가 메인언어가 되어버렸다니깐요 ㅎㅎ
보통 변화가 잦은 데이터같은거 html이랑 json이 분리되서 오는 경우가 잦아서, 특정 사이트 정보 크롤링할 때 json쪽 링크 찾아서 자유접근가능하면 그거 썼는데, 최근 학식 메뉴 가봤는데 그냥 처음부터 다 때려박혀져 있더라고요. 그래서 와 처음부터 페이지를 다 만들어서 보내버리네 이러기도 하는구나.. 하고 있는 찰나에 서버사이드 렌더링이 주가 된다는 영상을 봐서 기분이 좋네요.
SSR이 최신기술인것 마냥 소개가 되었는데 SSR은 오래전 jsp servlet할때부터 있었던 개념이죠 요즘은 SSO등 중요성이 부각되면서 다시 관심을 끄는 추세이긴한데 유행따라다니지 마시고 만들어야하는 서비스에 따라 맞춰서 개발하세요 어차피 다 해야됨 ㅋ 그리고 프론트엔드는 그냥 웹html이 아니라 사용자에게 보여지는 화면, 모바일 앱, 디바이스 UI를 모두 포괄하는 개념입니다 우리나라는 디자인, 퍼블이란 개념을 만들면서까지 분업하는 문화가 있어서 프론트가 죽을 일은 없습니다
SSR은 호랑이 담배피던시절부터 있던거고, 단지 SPA, CSR 언어들(Vue, React 등)이 서버사이드까지 확장해나가니, 요즘 새로 개발되고 공개되는 신규 언어들은 기본적으로 서버사이드를 탑재하는게 거의 디폴트가 되가고 있죠. 이전에 서버사이드라고하면 보통 자바나, Node 등을 사용했겠지만 Nuxt, Next같은 풀스택 서버 프레임워크들이 나오면서 React나 Vue하나만으로 CSR, SSR, SSG등을 모두 커버가 가능해지다보니 CSR만 하던 프론트쟁이분들도 SSR도 배워야할 필요성이 늘어나는거죠, 시장의 수요도 자바 백엔드가 아닌 이러한 수요도 늘고있고, 프론트는 하나만 가지고 밥벌어먹고살기에는 트랜드가 빠르죠. 그래도 겁먹으실필요 없습니다. 프론트영역은 항상 그래왔으니까요. 어차피 수요가 있는 것만 씁니다. 적어도 한국에서는요
3:26 에 'use client' 쓰면 CSR이라고 표현했지만, 사실 기존 pages 디렉토리로 만들던 hydration SSR 방식의 컴포넌트 렌더링입니다. Server Component(신규) Client Component(pages디렉토리의 SSR) 이 되는거죠 처음엔 저도 저렇게 알고있었는데 실제로 해보니 SSR로 동작되서 당황했네요.
