Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
과제 체크포인트
배포 링크
기본) https://areumh.github.io/front_6th_chapter4-1/vanilla/
기본과제 (Vanilla SSR & SSG)
Express SSR 서버
<!--app-html-->,<!--app-head-->)서버 사이드 렌더링
클라이언트 Hydration
window.__INITIAL_DATA__스크립트 주입Static Site Generation
심화과제 (React SSR & SSG)
React SSR
renderToString서버 렌더링React Hydration
Static Site Generation
구현 과정 돌아보기
가장 어려웠던 부분과 해결 과정
ssr ssg 환경에서 클라이언트와 서버에서의 라우터를 안전하게 공존시키는 부분이 어려웠다. 과제를 하기 전엔 ssr를 단순히 서버에서 html을 먼저 내려준다 정도의 사전적 정의 정도로만 이해하고 있었기 때문에 사이트의 각 페이지마다 어떻게 서버가 html을 생성해주는건지 잘 상상이 가지 않았다.
구현하면서 새롭게 알게 된 개념
클라이언트와 서버에서 라우트 정보를 일치시켜야 초기 렌더링과 하이드레이션이 가능하다는 것, 서버는 도메인 루트 기준으로 라우팅을 처리하기 때문에 인자로 base_url을 넘겨줄 필요가 없는 것 등을 알게 되었다.
추가로 이번 과제를 통해 renderToString이라는 함수를 처음 접하게 되었다. 처음 들었을 땐 과제로 제공된 유틸 함수인 줄 알았으나 ReactDOMServer 패키지에서 제공하는 함수였다. renderToString 함수는 동기적으로 컴포넌트를 html 문자열로 변환하므로 렌더 전에 서버에서 필요한 비동기 데이터를 반드시 마쳐야 한다는 것을 알게 되었다!
성능 최적화 관점에서의 인사이트
학습 갈무리
Q1. 현재 구현한 SSR/SSG 아키텍처에서 확장성을 고려할 때 어떤 부분을 개선하시겠습니까?
Q2. Express 서버 대신 다른 런타임(Cloudflare Workers, Vercel Edge Functions 등)을 사용한다면 어떤 점을 수정해야 할까요?
Q3. 현재 구현에서 성능 병목이 될 수 있는 지점은 어디이고, 어떻게 개선하시겠습니까?
Q4. 1000개 이상의 상품 페이지를 SSG로 생성할 때 고려해야 할 사항은 무엇입니까?
빌드 시간 최적화, 빌드 실패 시의 복구 전략 등
Q5. Hydration 과정에서 사용자가 느낄 수 있는 UX 이슈는 무엇이고, 어떻게 개선할 수 있을까요?
인터렉티브 전까지 사용자의 액션에 대한 무응답에 대해 스켈레톤 ui나 주요 부분만 즉시 하이드레이트하는 등의 기능으로 개선할 수 있다.
Q6. 이번 과제에서 학습한 내용을 실제 프로덕션 환경에 적용할 때 추가로 고려해야 할 사항은?
페이지 로드 에러에 대한 재시도, 이미지 최적화, 빌드 성능 개선, 모니터링 체계 등
Q7. Next.js 같은 프레임워크 대신 직접 구현한 SSR/SSG의 장단점은 무엇인가요?
커스텀 요구 사항에 대해 유연하게 구현이 가능하고, ssr와 ssg의 동작 원리를 코드를 통해 직접 이해할 수 있다.
하지만 next.js가 제공하는 기능을 직접 구현해야 하며, 유지보수 부담이 크다.
Q8. Next.js 를 이용하여 SSG 방식으로 배포하려면 어떻게 해야 좋을까요?
getStaticProps - 빌드 시점에서 데이터를 불러와 정적 html을 생성
getStaticPaths - 다이나믹 라우트에 대해 사전 생성할 경로를 정의
next build && next export - 정적 html을 생성하여 배포
코드 품질 향상
자랑하고 싶은 구현
개선하고 싶은 부분
리팩토링 계획
학습 연계
다음 학습 목표
실무 적용 계획
리뷰 받고 싶은 내용