Static Site Generation

서버 > 클라이언트 > 유저: 타이밍 중요
뉴스 기사, 상품 소개페이지 :  자주 바뀌지 않고, 자주 업데이트 되지 않고, 한번 컨텐츠가 나오고 나면, 계속해서 렌더링 하는 것.  => 자주 update됨

API > DB 접근 자체를 줄일 수 있는 방법이 있지 않을까? > SSG 탄생: 사이트를 빌드하는 시점에 미리 html을 생성함
html을 다 만들어놓고 미리 만들어놓은 정적 사이트를 유저에게 전달함으로써 사이트를 사용하게 됨 
API 접근하는 비율: 사이트 생성 시에만 접근하게 됨. 다른 방식보다 API 접근에 대한 부하 자체가 줄어듦
빌드 > html, css, js > s3, cdn에 올림 > user에 그대로 내려줌
이미지, 비디오 같이 정적 컨텐츠 내려줄 때 cdn내려줌 > 컨텐츠 딜리버리에 초점 맞춰져 있음 > 대용량 트래픽에 최적화 > 트래픽 아무리 튀더라도 어지간하면 안 죽음
cdn이 죽으면 어지간한 사이트는 죽는다고 봐야함
자주 갱신되지 않는 컨텐츠에 대해서는 최적

 

- 어떤 것이 가장 효율적일까?

: 섞어서 쓰면 된다. Static Site Generation / SSR, CSR등의 특징들을 섞어서 쓰는 것이 좋음 

 

- Next.js

: SSG + SSR 모두 지원. SSG : 상세페이지에 적합 /  SSR은 다름

 

- Gatsby

: SSG에서 뚜렷. 정적 사이트를 만드는 데 필요한 테마 등 모든 것들을 정의 내려줌. 정적 사이트 생성에만 최적화. 

 

- SSG 관점에서는 Gatsby가 더 잘해줌. 모든 아키텍처는 반드시 하나만 하라고 있는 것은 아님

- SSG, SSR, CSR 중 맞는 비즈니스를 선택하라고 있는 것. 

ex. 장바구니 => 실시간성 보장이 중요. 금액이 바뀔 수도 있고, 품절될 수도 있어서 CSR이 유리. API랑 지속적으로 통신하면서, 지금 가격이 얼마고, 옵션이 바뀌는 대로 렌더링 해야하므로.

 

ex. 상품상세 => 데이터가 자주 바뀌진 않음. 바뀌더라도 하루이틀 늦게 바뀌는 것 상관 없음. 단, 옵션, 품절, 금액은 빨리 바뀔 수록 좋음. 왜냐면 품절이 됐는데, 유저가 보는 사이트가 품절이 안되면 문제임. 상품 상세 페이지 자체는 SSR, SSG로 만들 순 있어도 금액, 옵션, 품절 등은 CSR로 구현하는 것이 유리. 실시간 성으로 상품 데이터 가져오고, 금액이 얼마 바뀌었네를 실시간 렌더링 시켜주는 것이 좋음

 

ex. 블로그, 기사 => 실시간성이 중요하지 않을 수 있음. 100% SSG로 구현할 수 있음. 블로그 글 갱신한 게 몇 분후에 바뀐다고 타격이 크진 않음. SSG로 해도 크게 이슈 없음

 

렌더링 방식을 조화롭게 섞어 쓰는 것이 중요. 아키텍처를 잡아 놓고 SSR, SSG를 둘다 지원해야하므로

 

ex. Gmail같은 걸 만들어야 해 => 실시간성 보장이 중요. CSR

해결하고싶은 문제가 뭐냐, 그 문제가 어떤 렌더링 방식에 적합한지를 체크해서 서비스를 만들어 유저들에게 더 나은 걸 제공할 수 있도록. 

 

참고: 오픈소스 블로그 기술의 새 바람! 정적 페이지란? (lgcns.com)