SSR, CSR 기준
서버 DOM을 구성하기 위한 데이터를 서버에서 제공하느냐 클라이언트에서 동적으로 생성하느냐에 따라서 SSR, CSR이 나눠지는 듯 하다. 처음에 기준이 잘 안잡혀서 이해하는데 어려웠다.
SSR
SSR은 Sever Side Rendering으로 서버에서 데이터를 가져와 데이터 맵핑을 한 후 클라이언트에게 전송을 해준다. 클라이언트는 받은 데이터를 기반으로 렌더링을 진행한다.
CSR
초기 서버 요청 시 html(하나의 페이지), js, css를 모두 받아온다. 그리고 난 후 javascript로 DOM을 생성하고 DOM 생성 시 필요한 데이터는 API 서버 호출을 통해서 받아온다. DOM구성을 javascript로 동적으로 구성하기 때문에 Client Side Rendering이라고 한다.
SPA
SPA는 하나의 html을 가지고 어플리케이션을 구성하기 때문에 Single Page Application이라고 한다. Vue, React, Angular는 SPA 형태의 어플리케이션을 개발하는데 사용한다. 이와 반대되는 개념으로 MPA이며 URI 변경 시 서버에 화면을 위한 데이터를 요청하고 렌더링한다.
CSR과 SSR 혼용(React Next.js, Vue Nuxt.js)
ngular, React, Vue SPA 삼대장들이 출시되고 나서 SPA의 단점을 극복하고자 많은 노력들이 있었지만, 정통 SSR(MPA) 방식의 장점을 완벽하게 커버하기란 불가능 하였다. 그래서 SSR(MPA) 방식에서 SPA의 장점 중 일부라도 누려보기 위해서 나온 프레임워크가 Next.js(React 기반), Nuxt.js(Vue 기반)들이 아닐까 추측된다.
일반적으로 Vue는 CSR로 작동을 한다. 웹서버 배포를 위해서 빌드를 하면 CSR를 진행할 수 있도록 리소스가 생성된다. Nuxt.js는 Vue SSR을 지원해준다. 페이지의 첫번째 화면은 SSR로 가져오고 해당 페이지에 대한 동작은 CSR로 작동한다. SSR과 CSR이 혼용되어있다.
- 기존 SSR을 사용하면 서버에서 페이지 틀을 만들어주고 자바스크립트는 프론트영역이 되었었다. 이렇게 되면 영역이 잘 구분이 안된다.
- CSR을 통해서 프론트와 백엔드 영역이 분리되었다. 하지만 CSR의 SEO문제와 화면속도 문제의 단점이 발생하였다.
- CSR영역에 SSR을 도입한다. 페이지틀을 만드는 부분를 API 서버와 별로도 분리된 SSR서버로 구성하여 페이지를 받고 CSR로 화면을 구성하는 것이다. 레퍼런스 글들을 참조해보니, 주로 node.js 기반의 서버를 사용한다. 프론트엔드는 주로 javascript로 작성하기 때문에 node.js로 SSR을 만드는 것이 쉬울 것이다.
- Vue는 CSR과 SSR 영역 둘다 지원해주는 기능이 있다. 그것은 바로 nuext.js 이다.
Nuxt
이전 vue-cli를 보면 build의 결과물이 정적파일들만 있었고, 그 정적파일을 웹서버(nginx, github pages, netlify, amazon S3 등)에 올려서 접근만 하면 사용이 가능했다. SPA가 배포가 간단한 것은 정제된 정적파일을 올리기만 하면 된다는 점이고, SSR을 하기 위해선 이처럼 화면을 그려줄 서버가 추가로 필요하여서 비용(과정, 난이도, 시간 등)이 더 들게 된다.
Nuxt SPA
Nuxt SPA의 경우 빌드 시 라우팅 화면 마다 *.html을 생성하긴 하지만 안에 내용을 보면 비어있다. 웹서버에 해당 리소스를 올리면 SPA를 사용할 수 있다.
Nuxt SSR
Nuxt SSR의 경우 빌드 시 node.js 기반의 서버 리소스가 나온다. 해당 리소스를 node.js에서 가동해주면 SSR서버가 구동된다.
SSR은 초기 진입 페이지를 서버에서 불러와 페이지를 렌더링한다. 즉 페이지를 그려주기 위한 서버가 필요하다.
그러나 초기 진입 이후에 앱 내 링크를 통해 이동하면 바뀐 화면 부분만 렌더링이 되는 것을 확인할 수 있다.
결과적으로 모든 페이지가 SSR이 되는 장점도, 그 이후에는 SPA의 장점 또한 가질 수 있다.
- SSR
말 그대로 Server Side Rendering을 수행하는 방법입니다.
서버에서 HTML 파일을 전해주기 전에 스크립트를 실행하는 방법인데,
자바 서버에서는 Nashorn이나 셀레니움(혹은 PhantomJS)등을 활용할 수 있습니다.
하지만 어떤 방법을 선택해도 스크립트를 실행하는 과정 자체가 오버헤드를 발생시킨다는 점은 피할 수 없습니다.
Nuxt Static Web
Pre-rendering으로 정적 HTML을 미리 만들어두었다. 이 소스를 웹서버에 올려두면 정적 파일을 다운로드하여 SSR을 구성할 수 있다.
서버에서 HTML을 클라이언트로 전해줄테니, 그 파일 안에 스크립트를 실행한 결과(DOM)를 미리 만들어 넣어두는 방법입니다.
꽤 멋진 방법입니다. 간편하게 적용할 수 있고, 별다른 로직 구현이 필요하지 않습니다.
하지만 페이지가 동적으로 자주 변한다면 어떨까요?
- Nuxt.js는 Vue 애플리케이션에 기반한 정적 웹 사이트 생성을 지원합니다. Nuxt는 모든 페이지를 사전 렌더링하고 필요한 HTML을 포함시킬 수 있으므로, "양쪽에 최선"으로 서버 없이 SEO 혜택을 가질 수 있습니다.
Nuxt의 명령어를 하나씩 살펴보며 알아보았다. 나는 단순히 SPA와 SSR의 차이만 알고 있었을 뿐, 실제로 Nuxt가 어떤 방식을 제공하고 있는지는 몰랐다. Pre-Rendering이란 뭔지, SSR에 서버가 필요할 때는 언제인지, SPA는 언제 사용하면 좋을지에 대해서 잘 이해하고 있어야 한다. 그래야 구현하려는 서비스의 특징에 맞게 적절한 방법을 고를 수 있겠다.
