전통적인 웹은
Browser - web server, app server, db 이런식으로 구성되어있다.
그에 반해 serverless 웹은
서버 시스템을 가상의 클라우드 환경에 두고 운영. 직접적인 서버 운영 및 인프라에 들어가는 비용 절약. 개발 생산성 향상. netlify, firebase, lambda 등
Browser API Gateway, colud Function storage (faunaDB, DynamoDB) 로 대체
JAM Stack 역시 serverless 웹에서 파생되었다.
JAM Stack의 공식 문서에서는 웹 애플리케이션에서 렌더링 할 화면을 Pre-render하고 이를 CDN에서 제공(delivery)하여 빠르고 안전한 앱으로 웹서버를 관리하거나 실행할 필요가 없다고 한다.
JAM Stack은
javascript, API, Markup
- j: 동적인 요소, api 요청 라이브러리 프레임워크
- api: 서버 또는 db에서 담당하던 역할, 추상화된 재사용 가능 api, cloud Function
- Markup 문서 내용의 시각적 표현, 빌드 시 페이지 생성 . 각각의 페이지를 사전에 생성함. prebuilt pages → 서버 없이 배포 운영되는 모던 웹 개발 구조
정적 사이트 생성기라는 것을 사용해서 개발 함. 빌드 되면 정적인 페이지들이 결과물로 산출 → cdn을 통해 전송, 별도로 추상화된 함수나 서비스를 사용해서 api 사용.
빌드시에 페이지를 미리 생성하기 때문에 훨씬 간단한 구조로 운영됨.
장점: 높은 안정성. 정적페이지를 미리 생성하기 때문에 동적으로 변경되는 부분이 적고, 서버나 db 의 실행이 필요하지 않기 때문에 공격에 노출되는 범위가 적다.
빠른 성능. 보여줄 컨텐츠들이 페이지로 미리 다 생성되어 있기 때문에 굉장히 빠른 렌더링
cdn을 통해 빠르게 전송. cdn이 제공하는 캐시의 이점도 누릴 수 있음.
확장성 및 낮은 비용. 전세계 어디든cdn을 통해 확장 가능하고. 정적인 html의 호스팅 비용은 매우 저렴하거나 공짜로 제공하는 서비스들도 있다.
빌드 및 배포 과정을 손쉽게 자동화할 수 있다. 빌드 산출물이 단순한 정적페이지들이기 때문에 배포과정이 매우 단순.
초기 로딩 속도 향상. db랑 연결 안 해도 돼서 좋음..
toast ui brand site 또한 그렇다. 사용법 등을 깃헙 wiki에서 마크다운으로 관리 했는데 사용자가 찾기 어려웠고, 내부적으로도 문제가 있었다. 그래서 갯츠비라는 정적 사이트 생성기를 사용해 생성했다.
정적 사이트 생성기 → Gatsby(react), Next.js(react), Nuxt.js(vue), 11ty(js), Hugo(go), Jekyll(ruby)
Gatsby React.js 기반의 정적사이트 생성기
다양한 데이터 타입 지원, 거대한 플러그인 시스템, GrahpQL을 통한 데이터 조회
갯츠비는 json, yaml, markdonw 등 많은 타입 지원, 갯츠비 plugin을 사용해서 GraphQL 노드로 변환. 변환된 노드는 graphql 쿼리를 정의해서 조회할 수 있고, React 컴포넌트에서 조회된 데이터를 컨텐츠로 사용. 최종적으로 빌드시에 리액트 컴포넌트들을 조합해서 페이지 생성.
JAMstack 생태계
cms: netlify, sanify, Contentful
함수: netlify, lambda, cloud function,
호스팅: firebase, netlify, githubpage 등등
동적 콘텐츠
검색결과, 쇼핑몰, 사용자 프로필 등은??
예측이 어려운 동적 컨텐츠는 jamStack에서 문제가 될 수 있음.
근본적인 문제 해결을 위해서는 문제해결을 위한 api나 저장소가 결국 필요함
다행히도 검색 쇼핑 결제등 다양한 third party apis를 사용가능. 대부분이 api는 서비스 규모에 따른 가격정책이 있기 때문에 잘 선택해야한다.
JAM Stack의 미래와 현재
JAM Stack의 현재
빠른 성능과 높은 안정성, 다양한 정적 사이트 생성기, 훌륭한 생태계
JAM Stack은 웹의 미래?
그럴수도, 아닐 수도 있다.
한계점: 빌드 속도, 대량의 페이지인 경우에는 빌드 시간이 길어진다.
실시간 변경 콘텐츠 반영에 시간이 걸릴 수 있음. 컨텐츠의 변경 사항을 빌드를 수행해야하기 때문에 즉각즉각 업데이트 하기 어려움.
별도의 CMS나 API를 사용해서 해결할 수 있지만, 모든 콘텐츠들에 대해서 사용하는건 JAMstack에서 비효율적. 그리고 빌드 속도 개선에 대한 근본적인 해결책이 아님.
갯츠비는 점진적 build라는 실험적인 기능 발전 중. 변경된 부분만 빌드 하는 것.
점진적 빌드를 도입하여 20분이 걸리던걸 1분으로 줄이고 그다음 빌드에선 10초가 걸림.
Next.js도 도입 중
웹의 미래? 점진적 빌드가 얼마나 발전하느냐에 따라 달라질 것 같다. 누구도 미래는 알 수 없다.
