ODL

그리고

ODX-WEB-FRONT

ODK Media

김태희

ODL 개발을 시작하며

"ODC와 복사해서 컬러만 바꿔서 만들어주세요"

처음 들어온 요구사항

ODC의 구조

• cloudfront에서 어떤 path로 요청을
  넣어도 index.html을 내려주도록 세팅함
• index.html에선 react-router를 통해 url path를 보고 client에서 라우팅 처리
• 결국 모두 static한 파일들이기 때문에
  s3(혹은 다른 CDN들)에 배포하면 배포 끝

개선하고 싶었던 것

• Server side rendering 도입
  • lighthouse 점수
    • Client Side Rendering 방식의 특성 상
      lighthouse에서 지표로 삼는 점수들이
      낮을 수 밖에 없음
    • 이 지표가 SEO 지표에 반영된다고 하여
      개선하고 싶었던 포인트
      사실 이거 한다고 개선이 안 되는 것이 광고 때문에..

무엇보다도..

작업 방식

• ODL과 ODC에서 공통으로 쓸 수 있는 것들(각종 유틸리티 함수 및 컴포넌트)를 별도로 분리
• 위에서 만든 것을 사용하여 화면을 구성하도록 ODL 프로젝트를 세팅
• SSR을 위해, next.js 적용

monorepo

lerna

• monorepo 관리 툴
• odx-web-front라는 저장소에
  • odx-web-base, odl 두 프로젝트를 세팅
• odl에서 odx-web-base를 install해 쓰는 구조
• 별도로 패키징 처리 하지 않아도 알아서
  packages 내에 프로젝트를 link 해줌

• odx-web-base 코드 변경 시 자동으로
  사용되고 있는 패키지들에 적용됨 

• 각종 컴포넌트들
• graphql 스키마 정의값
• type 정의
• hooks, utils

next.js

react로 Server Side Rendering을 하기 위한 종합선물세트

next.js

• odx-web-base에 있는 컴포넌트를 조합하여
  실제 ODL 페이지들을 구성함
• odx-design-system 덕분에 ODC와 컬러가 달라지는 부분은
  odx-web-base 코드 변경없이 손쉽게 적용 가능했음
• 같은 페이지를 브라우저에서 맨 처음 들어왔을 때는 SSR로,
  페이지 내 라우팅을 통해 들어왔을 때는 CSR로 렌더링 처리함
• 내장 모듈인 next/link, next/image 등을 통해 얻을 수 있는 여러가지 장점들이 있었음

next/link

• SPA처럼 링크를 처리해주는 모듈
• 기본적으로 prefetch를 지원
  • Link 컴포넌트로 연결된 url의 정보를 미리 로딩 해두어서 페이지 이동 시 바로 해당 정보를 적용하는 기술
  • 페이지 전환이 무척 빨라지는 편리한 부분이지만, 현재는 껐음

next/image

• image의 비율처리, lazy loading 처리 등을 해주는 컴포넌트
• 이미지 퀄리티 변경, 리사이징 등 가능
• 그외 각종 이미지 최적화를 해줌

SSG

Static Site Generate

• Server side rendering의 경우, 매 요청을 받는 Server가
  필요하기 때문에 트래픽에 따라 Server 증설 등이 필요
• 아예 Server side rendering 결과물을 정적인 HTML로
  만들어놓고 제공하는 방법
• Client 입장에서는 서버에서 SSR된 결과물을 받아서
  렌더링하나 정적 생성된 결과를 렌더링하나 똑같기 때문에
  가능한 방법

사실 ODC에도 적용하려고 했었어요

• 정적 생성이기 때문에, 데이터가 변경되면 다시 빌드해서
• 배포를 해야하는데
• 데이터 변경분만 빌드해서 배포하는 증분 빌드 파이프라인을
  만들었어야했고
• 그러기엔 일정이 빡빡했기 때문에 포기

그리고 이제 ISR이 나옵니다.

Incremental
Site
Regeneration

ISR은 또 무엇인가?

• SSG의 경우, 정적 생성이기 때문에 아까 앞에서 이야기한대로 변경된 데이터를 적용하려면 다시 빌드하고 배포해야함
• 그런데 매번 모든 페이지를 정적 생성하고 배포하는 건 굉장히 비효율적이기 때문에
• 변경분에 대해서만 증분 생성하는 방식

우리의 구원투수. revalidate

• 이 문제를 next.js에서는 revalidate라는 개념으로 접근
• 기본적으로는 SSG 방식으로 정적 생성된 파일을 제공하지만
  페이지별로 세팅된 이 값에 따라 세팅해둔 값만큼의 시간이
  지난 후에 들어온 요청에서는 해당 페이지 다시 빌드 후 제공
• 이를 위해 별도의 애플리케이션 서버가 떠있는 상태이긴 함
• 이 개념을 이용하면 기존 SSG에서의 부담이었던 모든 페이지의 정적 생성을 할 필요가 없고, 페이지 요청 시에 빌드해서 제공 할 수 있게 됨

우리의 구원투수. revalidate

• 단점으로는, 페이지가 빌드되는 시간이 좀 있기 때문에
  정적 생성되어 있지 않은 페이지를 방문하거나 마침 페이지를
  갱신하는 타이밍에 들어오는 유저에겐 약간 느리게 느껴질 수 있음
  • JSP에서 서버 기동 후 처음 들어온 사람에겐 느렸던
    그런 느낌과 유사함

결과적으로

• ODL에서 주요 컨텐츠 페이지는 5분 단위로 정적 생성 캐시가 적용되어 있음
  • Home, Category Landing, Program, Episode 등
  • 아직까지는 이걸 강제로 purge하는 방법은 없고, 정 급하면
    다시 빌드 - 배포하면 되긴 함
  • API 캐시와는 아예 별도의 이야기이므로 커뮤니케이션 시
    혼란을 초래할 수 있는 문제가 있음

그래서 지표가 어떻게 달라졌냐면..

Home - desktop

ODC

ODL

production 기준

그래서 지표가 어떻게 달라졌냐면..

Home - mobile

ODC

ODL

production 기준

그래서 지표가 어떻게 달라졌냐면..

Category Landing - desktop

ODC

ODL

production 기준

그래서 지표가 어떻게 달라졌냐면..

Category Landing - mobile

ODC

ODL

production 기준

그래서 지표가 어떻게 달라졌냐면..

Program - desktop

ODC

ODL

production 기준

그래서 지표가 어떻게 달라졌냐면..

Program - mobile

ODC

ODL

production 기준

광고, 외부 스크립트 등에 의해

깎이는 점수는 어쩔 수 없지만

전체적으로 성능 점수는 향상됨

이런 정적 생성 기반의 기술을 Jamstack이라고도 부릅니다.

next plan

ODC에도 적용하기

• ODL에 적용한 작업을 ODC에도 적용하기
  • odx-web-front에 odc를 이전
  • 이전하면서 odl의 최적화를 적용

ODK에도 적용하기

• 작년에 만들었던 odk-front-server를 없애고 해당
  프로젝트의 컴포넌트를 odx-web-front의 odk 패키지로
  옮기기
• ODL, ODC에 사용한 ODX 플랫폼을 이용해 아예 새로운 ODK 파일럿 해보기

Admin도 옮겨오기

• odx-admin-front를 odx-web-front의 package로 옮기기
• 이렇게 할경우, odx-web-base에 있는 컴포넌트를
  odx-admin-front에서 가져다 쓸 수 있음
• Admin 고도화의의 끝판왕,
  실시간 미리보기 구현 가능

기타 참고자료

https://slides.com/rotoshine/hello-jam-stack

작년 LTE에 만들었던 자료입니다.

Q&A

감사합니다.