vlwkaos' digital garden
nextjs
page 단위로 라우팅 제공 (라우팅별 번들을 받으므로 code splitting)
SSR, CSR(with SWR), SSG, ISR 입맛에 맞게 조리할 수 있다.
getServerSideProps
데이터까지 미리 렌더링해서 내려주고 싶을 때 사용.
페이지에 요청이 들어오면 해당 함수가 실행되면서 데이터를 가져오고, 페이지를 렌더링해서 서빙
요청마다 서버에서 결과를 처리해야하기 때문에 정적페이지로 내려주는 것보다 지연시간이 더 발생한다.
결과물은 CDN의
cache-control
헤더로만 캐싱이 가능하다.
꼭 필요한 게 아니라면 데이터 요청은 클라이언트에서 하는 것을 권장
의문점🤔
TTFB가 단축이 되어서 페이지 로딩이 빠르게 보이는 것은 맞다.
그 뒤에 hydration과정이 있어서 결국 react 관련 번들을 다운 받는데, 그럼 서빙하는 번들의 총 크기는 줄어들지 않아서 유저의 bandwidth 사용량을 줄여주지는 못할텐데 그럼 크게 볼때 조삼모사아닌가?
Next.js hydrate 최적화할 수 있나? - Partial hydration
Building Partially Hydrated, Progressively Enhanced Static Websites with Isomorphic Preact and Eleventy - Markus Oberlehner
[[Micro Frontend]]
가 트렌드라는데 큰 고민없이 단순히 프로젝트 관리단위만 나누게 된다면, 같은 프레임워크나 라이브러리를 수차례 받게되어 오히려 득보다 실이 많아질것 같기도하다. 어떤식으로 아키텍팅을 해야할까?
[[Micro Frontends Anarchy]]
를 조심하자
[[모던한 개발 프레임워크를 가져가면서 번들 사이즈를 줄이는 방법]]
nextjs