[6주차] 13, 14장 내용 정리

김효리/13. 렌더링 패턴/README.md

@@ -0,0 +1,106 @@
+- 콘텐츠를 어디에서 어떻게 렌더링 할 것인가?
+- 웹 서버, 빌드 서버, 엣지 네트워크 또는 클라이언트, 어디에서 콘텐츠를 렌더링 할 것인가?
+- 콘텐츠를 한 번에, 부분적으로, 또는 점진적으로 어떻게 렌더링 할 것인가?
+
+## 핵심 웹 지표
+
+- TTFB: 클라이언트가 페이지 콘텐츠의 첫 번째 바이트를 받는 데 걸리는 시간
+- FCP: 페이지 이동 후 브라우저가 콘텐츠의 첫 부분을 렌더링하는 데 걸리는 시간
+- TTI: 페이지 로드 시작부터 사용자 입력에 빠르게 응답할 수 있을 때까지 걸리는 시간
+- LCP: 페이지의 주요 콘텐츠를 로드하고 렌더링하는 데 걸리는 시간
+- CLS: 예상치 못한 레이아웃 변경을 방지하기 위한 시각적 안정성 측정
+- FID: 사용자가 페이지와 상호작용한 시점부터 이벤트 핸들러가 실행될수 있는 시점까지의 시간
+
+## 클라이언트 사이드 렌더링
+
+전체 웹 애플리케이션이 처음 요청 시에 모두 로드된다.
+
+페이지 렌더링의 경우 클라이언트에서 뷰를 갈아끼운다.
+
+장점: 페이지 간 라우팅이 빨라 사용자 경험에 좋다.
+
+단점: 큰 자바스크립트 번들로 인해 FCP와 TTI를 증가시킨다.
+
+## 서버 사이드 렌더링
+
+모든 요청마다 HTML을 생성한다.
+
+사용자 쿠키 정보나 요청 데이터를 기반으로 하는 개인 맞춤형 데이터를 포함하는 페이지에 적합하다.
+
+즉, 사용자에게 민감한 데이터를 서버에서 처리할 수 있다.
+
+SSR의 핵심 원칙은 HTML을 서버에서 렌더링하고 클라이언트에서 다시 하이드레이션하는 데 필요한 자바스크립트를 함께 제공하는 것이다.
+
+장점: FCP, CLS에 좋다.
+
+단점: 소스코드를 작성할 때 항상 서버를 고려해야 한다.
+
+### 서버 사이드 렌더링은 만능이 아니다 - 리액트 딥다이브
+
+- 우선순위에 따라 SPA가 더 효율적일 수 있다.
+- 가장 뛰어난 SPA는 가장 뛰어난 MPA보다 낫다.
+    - 예를 들어 Gmail 같은 경우가 있다. 이미지 최적화, 코드 스플리팅 등 최적화 기법을 사용했기 때문이다.
+- 하지만 평균적인 SPA는 평균적인 MPA보다 느리다.
+    - 최적화 기법이 어렵다.
+
+## 정적 렌더링
+
+전체 페이지의 HTML을 빌드 시점에 미리 생성하며, 다음 빌드 때까지 변경되지 않는다.
+
+정적인 HTML 콘텐츠는 CDN이나 엣지 네트워크에 쉽게 캐싱될 수 있다.
+
+ex) 회사 소개, 문의하기, 블로그 페이지 등
+
+## 점진적 정적 생성
+
+정적 렌더링과 SSR을 결합한 방식
+
+동적 페이지는 사용자 요청 시에 on-demand 방식으로 렌더링 한다. 특정 시간 간격마다 캐시를 자동으로 무효화하고 페이지를 다시 생성할 수 있다.
+
+재검증이 백그라운드에서 진행되는 동안 사용자는 캐시된 버전을 보게 된다. 이때 애플리케이션 전체 재빌드가 필요하지 않는다.
+
+https://nextjs.org/docs/app/guides/incremental-static-regeneration
+
+## 스트리밍 SSR
+
+SSR이나 정적 렌더링을 사용하면 자바스크립트 용량을 줄여 페이지가 상호작용 가능해지는 시간인 TTI를 FCP에 더 가깝게 만들 수 있다. 여기에 스트리밍 방식으로 콘텐츠를 전송하면 TTI와 FCP를 더욱 단축할 수 있다.
+
+청크 (chunk) 단위로 순차적으로 클라이언트에 전송한다. HTML 청크가 도착하는 즉시 브라우저는 이를 렌더링한다.
+
+리액트의 `renderToNodeStream` 함수를 사용해 애플리케이션을 청크로 나누어 전송한다. 이렇게 수신된 DOM 노드에 `hydrate` 메서드를 호출하면 해당 이벤트 핸들러가 연결되어 UI에 상호작용할 수 있게 된다.
+
+## 엣지 SSR
+
+CDN의 모든 지역에서 서버 렌더링을 가능하게 하고, 콜드 부트 시간을 거의 0에 가깝게 줄여준다.
+
+활용 사례로는 사용자별 지역 특화 리스트 페이지가 있다. 필요한 부분만 엣지 렌더링을 하도록 선택할 수 있다
+
+## 하이브리드 렌더링
+
+여러 렌더링 방식을 결합한 방식.
+
+즉, Next.js처럼 CSR, SSR, SSG, ISR, Edge SSR 등을 필요에 따라 혼합 적용하는 경우를 말한다.
+
+| **값** | **의미** | **렌더링 전략** |
+| --- | --- | --- |
+| 'auto' *(기본값)* | Next.js가 자동으로 판단 | 데이터 fetch 방식에 따라 SSG/SSR 자동 결정 |
+| 'force-dynamic' | 강제로 SSR로 처리 | 매 요청마다 서버에서 렌더링 |
+| 'force-static' | 강제로 정적 처리 | 빌드 시 SSG, fetch 시 캐시 필수 |
+| 'error' | 정적 생성이 불가능하면 오류 발생 | 예외 처리용 |
+
+## 점진적 하이드레이션
+
+각 노드를 시간에 따라 하이드레이션하여 필요한 최소한의 자바스크립트만 요청하는 방식
+
+상대적으로 덜 중요한 부분의 하이드레이션을 지연시킨다. 서버에서 렌더링된 DOM 트리가 파괴되고 즉시 다시 생성되는 문제를 방지할 수 있다.
+
+## 아일랜드 아키텍처
+
+정적인 HTML 위에 독립적으로 전달될 수 있는 상호작용 아일랜드를 통해 자바스크립트의 전송량을 줄이는 패러다임을 의미
+
+### 점진적 하이드레이션과의 차이
+
+- 점진적 하이드레이션: 하향식 구조로 되어있다. 페이지가 개별 컴포넌트의 스케줄링 및 하이드레이션을 제어한다.
+- 아일랜드 아키텍처: 각 컴포넌트가 자체적으로 하이드레이션 스트립트를 가지고 있으며, 이 스크립트는 페이지의 다른 스크립트와 독립적으로 비동기 실행된다.
+
+단점: 소셜 미디어 애플리케이션과 같이 상호작용을 위주로 한 페이지에 적합하지 않다.

김효리/14. 리액트 애플리케이션 구조/README.md

@@ -0,0 +1,49 @@
+### 모듈, 기능 또는 경로별 그룹화
+
+```
+common/
+	Avatar.ts
+product/
+	index.js
+	price.js
+checkout/
+	index.js
+```
+
+장점: 모듈에 변경사항이 있을 때 관련된 모든 파일이 같은 폴더에 모여 있어 변경사항이 특정 코드 영역으로 제한된다.
+
+단점: 공통 컴포넌트를 주기적으로 파악해야만 중복을 피할 수 있다.
+
+### 파일 유형별 그룹화
+
+```
+css/
+	global.css
+lib/
+	date.js
+pages/
+	product.js
+```
+
+장점: 여러 프로젝트에서 동일하게 사용할 수 있다. 공통 컴포넌트의 스타일을 변경하면 전체에 적용된다.
+
+단점: 특정 모듈의 로직을 변경하려면 여러 폴더에 있는 파일을 찾아가 수정해야 한다.
+
+### 도메인 및 공통 컴포넌트 기반의 혼합 그룹화
+
+```
+components/
+	User/
+		profile.js
+domain/
+	product/
+		product.js
+```
+
+파일 유형별 그룹화와 기능별 그룹화의 장점을 모두 활용
+
+저도 취준 + 회사생활 하면서 계속 고민한 게 폴더 구조였어요.. 저 같은 경우에는 도메인 중심 구조를 선호하는 편이에요! 회사에서는 정석 구조인 레이어드 구조를 사용하고 있습니다.
+
+[테오 FSD](https://velog.io/@teo/fsd) (몇 달 전부터 FSD 아키텍처에 대한 글을 많이 봤지만, 전 볼 때마다 생소하고 적용하기 어려울 것 같더라구요 ㅠ 다른 분들은 사용해보신 적이 있으신가요 ?)
+
+다른 분들의 꿀팁들을 스터디 때 쓰윽 흡수해야겠습니다 😋