[ASAC 6기] 웹 개발이란 무엇이며, 어떻게 동작하나? FE(4) - Rendering Pattern

✅ Static Websties

정적 페이지를 반환하는 웹 서버(Nginx, Apache, S3) 활용

가장 초기의 웹 페이지 형태: 초창기 홈페이지는 한번 만들면 거의 변경될 일이 없었다.

 

이미 만들어진 웹 페이지인 정적 웹 페이지를 요청에 따라 반환하므로 렌더링 절차가 없었다.

그림에서 JS가 페이지를 Render하는 것은 이미 만들어진 페이지를 띄워주기 위함..

💡CDN( Content Delivery Network )
지리적으로 분산된 서버들을 연결한 네트워크로서 웹 컨텐츠의 복사본을 사용자에 가까운 곳에 두거나 동적 컨텐츠(예: 라이브 비디오 피드)의 전달을 활성화하여 웹 성능 및 속도를 향상할 수 있게 합니다.
ref: https://www.ibm.com/kr-ko/topics/content-delivery-networks

 

🔷 Static Websties 특징

🔹서버 불필요
    🔹 S3같은 storage에 정적 페이지를 담아놓고 반환해줘도 된다.(ex. github.io페이지 같은 경우 storage만 사용)
    🔹리액트 배포할 때도 트랜스파일링, 번들링해서 만들어진 JS, HTML, CSS를 스토리지에 업로드해서 배포한다. -> 서버 사용 X

장점:
🔹서버가 반환하고자하는 모든 정적 웹 페이지를 갖고 있어야한다.
    🔹 100명의 유저 정보 페이지  100개의 유저 정보 페이지)
🔹웹 페이지 버전 변경을 하려면, 매번 파일을 변경해줘야하여 번거롭다

단점:
🔹서버가 가지고 있는 정적 웹 페이지를 반환만 하면 되기 때문에 매우 빠른 웹 페이지 반환 속도
🔹구글과 같은 검색엔진 최적화(SEO, Search Engine Optimization)에 유리
    🔹웹 크롤러가 웹 페이지를 수집할 수 있다.

---

✅MPA(Multi-Page Application)= SSR(Server Side Rendering)렌더 = DOM 조작

동적 웹 페이지 생산 주체 = 웹 서버

동적 페이지를 반환하는웹 어플리케이션 서버(Tomcat(Spring Boot + Thymeleaf))활용

쇼핑몰과 같이 실시간성이 중요한 웹 페이지 형태 : 검색 필터에 따라 다른 결과 및 가격 변동에 예민
MPA 등장 배경 : 서버가 제공하려는 모든 정적 페이지를 저장하려니, 너무 많은 용량이 필요

 

서버는 요청에 따라 그때그때 동적 웹 페이지를 만들어 반환: 반복되는 템플릿과 실시간 정보를 분리한다.

🔹1000명의 유저 정보 페이지 = 1개의 유저 정보 페이지 템플릿 + 1000명 유저 정보 데이터베이스

🔹DB나 외부 API에서 데이터를 가져와서 뷰 템플릿과 결합한다.

 

View

동적 페이지를 반환하는 웹 어플리케이션에서 뷰를 반환한다.

뷰 = 뷰 템플릿 + 데이터(model)
템플릿 엔진: 뷰 템플릿과 데이터를 결합해주는 것

템플릿 엔진이  어떻게 뷰 템플릿과 데이터를 결합해줄나? 자바, 파이썬, node.js가 템플릿 엔진 역할을 한다. 

 

🔷Server Sid Template Engine: 템플릿 엔진이 웹 서버 측에 존재

1. 웹 서버에 CGI를 통해서 어플리케이션을 붙이는 경우

2. 웹 어플리케이션 서버 안에 어플리케이션 내포(현대 WAS 특징)

페이지를 만드는 주체가 어플리케이션이고, 어플리케이션이 뷰를 만들어서 서버에 전달하고 서버가 만들어진 뷰를 브라우저에 전달한다. (웹 크롤러가 완성된 웹 페이지를 수집할 수 있다.)

🔷MPA(=SSR) 특징

🔹서버 필요
🔹서버가 동적 웹 페이지를 생성하여 반환하기 때문에, 반환하려는 모든 웹 페이지를 갖고 있을 필요 X
    🔹웹 페이지를 만들고, 유저가 보기전까지 시간이 걸릴 수 있다.
🔹서버가 생성해서 반환하기에 웹 페이지 반환 속도는 DB조회 속도, 웹 페이지 생성 속도에 의존
    🔹웹 서버의 CPU, 메모리 자원이 사용되기 때문에 AWS 같은 클라우드 사용 시 비용 부담
    🔹비용 감소를 위한 serverless 사용(아래에서 설명)
🔹구글과 같은 검색엔진 최적화(SEO, Search Engine Optimization)가 가능
    🔹웹 크롤러가 웹 페이지를 수집할 수 있음.

 

💡왜 비용감소를 위해 Serverless를 사용하는가?

serverless와 server의 비용 차이는 호출 횟수가 적을수록 serverless가 유리하고, 호출횟수가 많아지면 server가 유리하다.

호출횟수가 적은 SSR을 사용한다면 serverless 를 사용하는게 비용 측면에서 유리하다.

*serverless에 대한 설명은 나중에 백엔드 편에 올라올 예정*

---

✅SPA(Single Page Application) = CSR(Client Side Rendering)

동적 웹 페이지 생산 주체 = 웹 브라우저

웹 브라우저 내 자바스크립트 활용해 동적 페이지 생성 + 자바스크립트 반환을 위한 웹 서버 or 저장소(S3)

🔷 SPA 등장 배경

웹은 필요한 페이지마다 요청해서 받아와야한다 -> 웹이 움직일 때마다 깜빡거린다.

앱은 화면 전환이 부드럽다. 이걸 Fast Rout Transition이라고 하는데 예시 홈페이지로 가서보면 화면 전환할 때 깜빡거림없이 부드럽게 전환된다.

 

모바일 앱과 같이 실시간 유저 인터페이스가 중요한 웹 페이지 : 페이지 이동이나 버튼에 따른 동작 부드러움
🔹SPA 등장 배경 : Fast Route Transition (모바일 앱과 유사한 화면 전환 및 사용성) ⇒ SPA Route
서버는 JS파일만 클라이언트에게 전달해주면 웹 브라우저는 빈 HTML에 JS를 가지고 전이하는 것이다.

🔷SPA(=CSR): 템플릿 엔진이 웹 브라우저에 존재

client side Template Engine: 템플릿 엔진이 웹 브라우저 측에 존재

웹 페이지 렌더링 과정

1. 빈 HTML, 번들링된 JS, 번들링된 CSS를 storage 혹은 웹 서버에 저장(Static Website와 동일)되어 있다.
2. 뷰를 만들기 위해 뷰 템플릿(빈 HTML)과 Model(데이터)을 가져온다.
   • 뷰템플릿은 스토리지나 웹 서버에서 가져온다. 
   • 데이터는 DB나 Open API에서 가져와서 API로 클라이언트에게 제공 -> 백엔드 개발자가 API 싸개가 된 이유
3. 웹 브라우저에서 템플릿 엔진을 통해 뷰를 만들고 렌더링한다.
   • JS 파일이 웹 브라우저에 도착하면 그때 빈 HTML에 렌더링해준다.
   • 모든 화면 전환을 웹 브라우저에서 한다.
   • 모바일 앱과 같은 최적의 사용성을 유저에게 제공: "웹 브라우저 위에서의 작은 모바일 앱"
   • 리액트의 등장으로 `웹앱`이라는 게 생겨났고, '웹앱 개발하자'라고하면 CSR하자는 말이다

🔷SPA(=CSR) 특징

장점:
🔹서버 불필요
🔹웹 브라우저가 동적 웹 페이지를 생성하여 반환하기 때문에, 웹 페이지 전환 시 깜빡임이 존재하지 X

단점:
🔹유저에게 최적의 사용성(UX)을 제공하려다보니 Bundled JS크기가 너무 크다: Initial Loading
🔹구글과 같은 검색 엔진 최적화(SEO, Search Engine Optmization)가 불가능
    🔹웹 크롤러가 웹 페이지를 수집할 수 없음
    🔹어떤 페이지가 있는지 클라이언트가 렌더링하지 않는 한 알 수가 없다: 웹 크롤러는 렌더링 못함 -> 최근 구글 웹 크롤러는 렌더링이 가능해서 SEO가 가능하다고 한다.

✅SSR with Hydration = MPA + SPA

템플릿 엔진이 웹 브라우저 / 웹 서버 양측 모두에 존재

동적 페이지를 반환하는 웹 어플리케이션 서버 활용 + 웹 브라우저 내 자바스크립트 활용해 동적 페이지 생성

Next.js, Nuxt.js, SveltKit 과 같은 모든 종류의 메타 프레임워크 Meta Framework 가 제공하는 기능
SSR 등장 배경 : CSR 의 Initial Loading 문제와 SEO 불가능한 단점 모두를 보완하기 위해
🔹SSR (Server-Side Rendering) ⇒ MPA
🔹with Hydration ⇒ SPA

 

💡Meta Framework

Next.js: 리액트의 Meta Framework

Nuxt.js: 뷰의 Meta Framework

SveltKit: svel의 Meta Framework

 

 

 

앱 라우터 등장

이전에는 페이지 단위로 SSR, CSR을 결정할 수 있었다.

SSR with Hydration은 컴포넌트 단위로 결정한다. 따라서 하나의 페이지에 SSR 영역과 CSR 영역을 복합적으로 섞어 쓸 수 있다.

🔹 페이지 라우터: SSR, CSR 사용 여부가 페이지 단위

🔹 앱 라우터: SSR, CSR 사용 여부가 컴포넌트 단위

 

SSR with Hydration - 웹 서버

서버에서 템플릿 엔진을 통해 CSR영역을 제외한 반쪽 짜리 HTMl 완성

DB 또는 API에서 CSR로 페이지를 그리기 위한 데이터를 API로 제공

번들링된 JS, 번들링된 CSS 파일이 스토리지나 웹 서버에 저장되어 있다.

-> 템플릿 엔진(번들링된 JS), SSR 결과(반쪽짜리 뷰), CSR에 필요한 데이터를 제공해줌

 

SSR with Hydration - 웹 브라우저

번들링된 JS(템플릿 엔진)를 통해 SSR의 결과(뷰템플릿)와 API로 가져온 데이터(Model)를 합쳐서 뷰를 렌더링 해준다.

 

🔷Hydration 개념

하나의 온전한 페이지를 유저에게 보여주는 3가지 방법

1. SSG
2. SSR
3. CSR

Hydration은 SSG, SSR 장점 위에 CSR 장점을 얹기 위한 방법이다.

1. SSG: 웹 페이지 내 비실시간성 요소들은 미리 준비하여 속도가 제일 빠르게 반환
2. SSR: 실시간성이 필요한 웹 페이지 내 부분은 웹 서버로부터 요청이 들어오자마자 만들어 반환
3. CSR: 모바일 앱과 같은 사용성을 제공하면 좋은 일부 요소들은 CSR로 렌더링하여 Budled JS 경량화

Hydration 적용 시 JS가 늦게 로드되기 때문에 짧은 시간동안 유저 사용성에 관련된 버튼 등이 동작되지 않는다.

 

✅SSG with Hydration

리액트 같은 프레임워크로 개발 및 빌드한 정적 페이지를 반환하는 웹 서버 활용: nginx, apache, s3

웹 프론트엔드 프레임워크(React, Vue 등)를 통해 CSR 개발하듯이 개발한 뒤 빌드하면 정적 페이지 생성
SSG: 등장 배경: SEO개선을 위해서 페이지 로딩 속도를 극단적으로 줄일 필요
🔹HTML, JS, CSS를 직접 생성하는 Static Websites과 달리, SSG는 빌드(Prerender)로 생성

🔷SSG with Hydration 특징

정적 페이지를 빌드 타임에 만드는것, SSR은 런타임에 동적 파일 만듦
🔹비실시간성 요소(헤더, 푸터, 네비게이션 바) 같은 것들은 SSR, CSR할 필요 없이 정적 파일로 존재해도 된다. -> 빌드시 SSG로 만들어서 스토리지나 DB에 저장
🔹 사용성이 중요한 부분은 CSR로 
static websites 특징과 동일 + CSR의 장점을 누릴 수 있도록 Hydration 추가
🔹모바일 앱과 유사한 사용성 제공 가능
🔹웹 브라우저가 동적 웹 페이지를 생성하여 반환하기 때문에, 웹 페이지 전환 시 깜빡임 존재X