chapter4, chapter8 정리

임지은/4주차/chapter4.md

@@ -0,0 +1,113 @@
+# 04. 서버 사이드 렌더링
+## 서버 사이드 렌더링이란?
+
+### SSR <-> SPA
+![alt text](https://img1.daumcdn.net/thumb/R720x0.q80/?scode=mtistory2&fname=https%3A%2F%2Ft1.daumcdn.net%2Fcfile%2Ftistory%2F997C153F5C1B2A7E05)
+
+    SSR 과 SPA의 궁극적인 차이!
+    "웹페이지 렌더링 책임을 어디에 두느냐"
+
+    SPA : 자바스크립트 번들에서 렌더링 담당
+    SSR : 서버에서 렌더링 작업 담당
+
+#### SPA (Single Page Application)
+- 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식
+- 최조에 서버에서 최소한의 데이터를 불러온 이후부터는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 "모든" 작동이 이뤄진다.
+- 단점 : 최초에 로딩해야 할 자바스크립트 리소스가 크다.
+- 장점 : 로딩된 이후에는 서버에 거쳐 필요한 리소스를 받아올 일이 적어지기 때문에 사용자에게 훌륭한 UI/UX를 제공해준다.
+
+-> 이 방법은 페이지 전환을 할 때, 최초에 서버에서 다운로드한 전체 리소스가 있기 때문에 새롭게 리소스를 다운로드 하지 않아도 된다. 훨씬 더 매끄러운 UI (ex.Gmail)
+
+<->
+
+#### 과거 SPA 애플리케이션
+- 페이지 전환이 발생할 때마다 서버에 새롭게 페이지 요청, HTML 페이지를 다운로드해 파싱하는 작업 거친다.
+
+-> 이 방법은 페이지 전환을 할 때 서버에 요청해서 다시 그리는 과정을 거쳐야 하므로 사용자 입장에서는 페이지 전환이 버벅거린다고 느끼게 된다. (ex. 네이버 스포츠 화면으로 전환)
+
+### JAM 스택
+#### 등장배경
+- 과거에는 SSR 방식을 이용했다. 페이지를 요청하면 서버에서 완성된 HTML을 내려받고, 또 페이지 이동이 있으면 새로운 페이지를 서버에서 내려받는 방식 <- 여기서 자바스크립트는 어디까지나 사용자에게 추가적인 경험을 주기 위한 보조적인 수단으로 이용
+
+- 자바스크립트의 모듈화가 진행됨
+- Backbone.js, AngularJS, Knockout.js 등장 (자바스크립트에서 어느 정도 서버에서만 할 수 있는 복잡한 작업을 할 수 있게 되었다.)
+- 자바스크립트의 역할 가중화 -> SSR의 유행 시작 -> JAM 스택 등장
+#### JAM 스택
+- (과거) LAMP 스택 
+
+    -> Linux(운영체제), Apache(서버), MySQL(데이터베이스), PHP/Python(웹 프래임워크)
+
+- JAM 스택 등장
+
+    -> JavaScript, API, Markup
+
+    -> 웹의 작동이 모두 사용자의 클라이언트에서 실행되므로 *서버 확정성 문제에서* 더 자유로워질 수 있다.
+
+    -> JAM 스택 인기 + Node.js의 고도화 
+
+    : MEAN(MongoDB, Express.js, AngularJS, Node.js) | MERN(MongoDB, Express.js, React, Node.js) 스택 등장 (아예 **API 서버 자체**도 자바스크립트로 구현하는 구조)
+
+### SSR
+- 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식
+
+#### 장점
+1. **최초** 페이지 진입이 비교적 빠르다.
+
+    서버에서 HTTP 요청을 수행하는 것이 더 빠르고, HTML을 그리는 작업도 서버에서 해당 HTML 을 문자열로 미리 그려서 내려주는 것이 더 빠르다.
+
+2. 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
+
+    검색 엔진(메타데이터)는 자바스크립트 코드를 실행하지 않는다.
+
+    따라서, SPA에서 검색 엔진을 사용하고자 한다면 메타 정보를 제공할 수 있도록 조치를 취해야 한다.
+
+    하지만, SSR는 최초의 렌더링 작업이 서버에서 일어나므로, 검색 엔진에 제공할 정보를 서버에서 가공해서 HTML 응답으로 제공할 수 있다.
+
+3. 누적 레이아웃 이동이 적다.
+
+    **누적 레이아웃 이동**
+
+    component1, component2 가 화면의 위 아래로 배치돼어있는데, 화면 렌더링 시 component2의 API 요청 응답 속도가 더 빨라서 먼저 화면에 나타나고, 조금 뒤 component2가 화면에 그려지면서 컴포넌트가 밀리는 현상
+
+    SSR : API 요청에 의존, API 요청의 응답 속도가 제각각이므로 이를 적절치 처리해두지 않으면 누적 레이아웃 이동 문제가 발생
+
+4. 사용자의 디바이스 성능에 비교적 자유롭다. 
+
+    SPA : 자바스크립트 리소스의 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적이다.
+
+    SSR : 부담을 서버에 나눌 수 있다.
+
+5. 보안에 좀 더 안전하다
+
+    SSR은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공하기 때문에 보안에 안전하다고 할 수 있다.
+
+#### 단점
+1. 소스코드를 작성할 때 항상 서버를 고려해야 한다.
+
+    window, sessionStorage와 같이 브라우저에만 전역 객체를 사용한다면, 'window is not defined'라는 에러를 마주하게 된다.
+
+    따라서, 
+
+    1. window를 사용하지 않던가, 
+
+    window를 꼭 사용해야 한다면 
+
+    2. 해당 코드가 서버 사이드에서 실행되지 않도록 해야 한다. ("use client")
+
+2. 적절한 서버가 구축돼 있어야 한다.
+
+3. 서비스 지연에 따른 문제
+
+### 현대의 서버 사이드 렌더링 
+(기존)
+- 최초 페이지 진입은 빠르지만, 이후에 라우팅이 발생할 때도 서버에 의존해야 하기 때문에 싱글 페이지 렌더링 방식에 비해 라우팅이 느리다.
+
+#### 요즘의 서버 사이드 렌더링은 SSR의 장점 + SPA의 장점을 합친 방식으로 작동한다.
+
+    [최초 웹사이트 진입 시]
+    서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받음
+
+    [라우팅]
+    서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동
+
+    => Next.js, Remix