Ajax & CSR (Client side rendering)
Asynchronous JavaScript and XML 이라는 이름에서 보듯 '비동기적인' 방식으로 디스플레이(보이는곳)의 뒤편에서 서버와 데이터를 주고받기 때문에 페이지를 다시 로딩하지 않고 변경이 이루어질 수 있다. DOM에 큰 뼈대인 테이블이 먼저 로드되고 Json 형식의 파일이 서버로부터 넘어와 나머지 부분들을 채워준다. HTML파일 head부분에 데이터의 표현방식과 페이지 상에서의 위치를 명시해준다 (e.g. 카드섹션 만들어서 가로로 붙이기).
Jinja2 템플릿 엔진 & SSR(Server side rendering)
Python을 이용하는 웹템플릿엔진으로 Django에서 영감을 받아 제작된만큼 이와 높은 유사성을 보인다고 한다. 대신 그보다 더 나아가서 실행이 'sandbox'에서 이루어지도록 제작되어 보안성을 높였다. 템플릿엔진을 사용하게 되면 코드가 간단하게 쓰여질 수 있는데, html파일에 template을 jinja 문법으로 구축하고 Flask 같은 서버 라이브러리로 데이터를 렌더링해 줘서 {{ }}안에 채워지면 되기때문이다. 유연하고 재사용 가능한 템플릿 기반으로 동작하므로 블로그나 온라인 쇼핑몰 등을 만들때 유용하게 쓰일 수 있다. HTML파일 body에 데이터가 들어와야하는 위치가 {{}}로 표시된다.
- 코드가 쓰인 부분이 각각 head의 script나 body 부분인데, head의 script에 적힌 부분이 나중에 브라우저로 온다는건 코드의 실행순서가 HTML -> CSS -> JavaScript라는 뜻일까?
그렇다면 서버사이드 렌더링 (SSR)과 클라이언트 사이드 렌더링 (CSR)이란 무엇일까?
서버사이드 렌더링 (SSR): 인터렉션이 발생할 때마다 서버로부터 새로운 html을 받아와서 해당 링크로 이동하여 페이지 전체를 새로 렌더링하는
전통적인 MPA (multiple page application)을 구현하는 방식이다 (Data format: html). 브라우저가 프론트엔드 서버에 요청을 하면 프론트엔드가 백엔드 서버로 요청을 릴레이해 데이터를 받아오고, 받아온 데이터는 프론트엔드 서버에서 html,css,js 파일들과 묶여 브라우저로 보내진다. 그리하여 완전히 만들어진 페이지가 통으로 로드되고 DOM operation은 필요하지 않다 (Renderer: Server).
클라이언트 사이드 렌더링 (CSR): SSR과 달리 CSR에서는 브라우저가 프론트서버와 백엔드서버에 따로 요청을 해서 프론트서버가 백엔드 서버의 데이터를 가져오지 않는다. 프론트엔드 서버에서 온 html,css,js같은 데이터가 더 빨리 브라우저에 전달되어 화면이 그려진후, 백엔드에서 온 데이터들이 채워진다 (Data format: JSON/XML/YAML). 따라서 DOM operation이 필요하다 (Renderer: Browser). 데이터의 공백이 생기면 블로그의 글이나 쇼핑몰의 제품 상세페이지 등이 뒤늦게 뜨는 것을 사용자가 경험하게 될 수 있다. 이를 해결하기 위해서 필요한 부분만 서버사이드 렌더링 방식으로 작동하게 하기 위해 next.js라는 라이브러리를 사용한다고 한다.
섞어쓰기?
좋은 ‘app shell’ architecture (사용자가 이용하는 최소한의 부분을 빠르게 로딩하고 cache를 이용해 재방문시 오프라인에서도 이용이 가능하도록 하는 전략)처럼 좋은 cache strategy를 짜서 쓸수있다고 한다!
e.g. 처음에만 SSR로 렌더링하고 cache에 저장한 후에 다음부터 불러오는 방식을 CSR로 바꾸기 (구체적으로 어떻게 할까?)
항상 그렇듯이 지금 쓰이는 방식들을 비교할땐 절대적으로 더 우월한 방식은 없다는 것! 있다면 다른방식이 도태되서 사라졌을테니까... 구성하려는 서비스와 사용자의 의견을 중점으로 더 좋은 방식을 선택해서 사용하자!
refs.
https://miracleground.tistory.com/165
saved material
https://developers.google.com/web/updates/2019/02/rendering-on-the-web
