GDSC Sookmyung 활동/10 min Seminar

SSR(서버사이드렌더링) vs CSR(클라이언트사이드렌더링)

dolphinSarah 2021. 3. 7. 22:47

새 창에서 열기

 

*시간 관계상 발표에 담을 수 없었던 부분에 대해 궁금한 점이 있으시면 아래를 참고해주세요. 

MPA(Multi Page Application)

일반적으로 웹사이트에 접속하려면, 서버에게 HTML 파일에 대한 요청을 보냅니다. 

그럼 서버는 요청받은 HTML 파일의 전송을 담당합니다. 

이렇다보니, 기존의 웹브라우저는 단지 보여주기만 할 뿐, 요청한 웹 문서에 대한 처리는 전부 서버에서 담당해왔습니다. (서버 살려,,,,,,) 

과거에는 웹에서 제공되는 정보가 그리 많지 않았고, 많다고 해도 페이지가 많이 나뉘어져 있었기 때문에 데이터를 쪼개서 보여줄 수 있었습니다. 

하지만 요즘은 하나의 페이지에서 보여줘야 하는 정보가 무궁무진하게 많고, 자바스크립트 기술도 발전하고, 컴퓨터 성능도 좋아지고 등의 이유로 더 많은 정보를 한 번에 보여줘야 할 필요성이 생겼습니다. 

그 결과, 페이지를 이동할 때마다 매번 새로운 정보를 보여줘야 하는 서버 측에서는 죽을 맛이었겠죠. 심지어 사용자가 늘어남에 따라 모든 사용자가 서버에게 본인의 페이지를 만들어 달라고 하니 서버 쪽에선 과부하가 걸릴 수 밖에요. 

또, MPA(Multi Page Application)의 단점은, 페이지 전환마다 새로운 HTML 파일을 요청하면, 사용자의 인터페이스에서 사용하고 있던 상태를 유지하기가 어려워지고, 바뀌지 않는 부분까지 다시 불러와야 하기 때문에 불필요한 로딩도 생깁니다. 

 

SPA(Single Page Application)

그리하여 SPA가 등장하게 되었습니다. 서버에서 하던 일을 브라우저에서 해결하도록 만든 것입니다. 

이게 가능한 이유는, JavaScript가 DOM을 건드릴 수 있는 script 언어이고, 웹브라우저에 쓰이는 유일한 프로그래밍 언어이기 때문입니다.  

단 하나의 index.html 파일만 가지고, 안의 내용물은 전부 .js 파일의 DOM 조작을 통해 채우게 됩니다. 

그러면 데이터베이스는 어떻게 연결하나요? 

과거에는 서버에 담긴 .jsp 파일이 있다면, 서버는 자바 코드를 통해 데이터베이스와 연결해 데이터를 가져와 이 .jsp에 담긴 결과물을 html처럼 만들어준 후 사용자에게 보내주었습니다. 

그런데, 어떻게 프론트엔드에서 JavaScript로 이걸 해결할 수 있을까요? 

이럴 때 사용하는 게, 대체적으로 REST API입니다. 

간단하게 말하면, URL을 통해 서버에게 어떤 행위를 요청하고 응답받는 것입니다. 

localhost:3000/posts/write (POST 방식)

이런 식으로 URL + 내용물을 서버에게 전송하게 되면, 서버쪽에서 데이터베이스와 통신하고 내용물을 저장해줍니다. 

즉, URL을 입력만 해줘도 데이터베이스와 소통하고 데이터를 보내줍니다. 물론 URL에 따라 서버가 어떤 동작을 취해야 하는지는 당연히 서버 쪽에 이미 정의되어 있어야 합니다. 

지금까지의 내용을 요약해보자면, 

  • 프론트는 JavaScript와 URL을 이용해서 서버에게 데이터를 요청하고 응답받습니다. 
  • SPA에서는 웹페이지가 JavaScript로 인해 렌더링됩니다
  • 서버는 URL을 통해 들어온 요청에 대한 응답만 해주면 됩니다. 

AJAX, JSON

SPA Lifecycle 사진을 보면, 데이터를 요청할 때 클라이언트 측에서는 AJAX를 사용하고, 서버쪽에선 결과물로 JSON 코드를 전송해줍니다. 

AJAX는 Asynchronous JavaScript and XML의 약자로, 페이지를 변경하지 않고 동일한 페이지에서 오로지 JavaScript를 통해 페이지의 내용물을 바꾸는 것을 말합니다. 

JSON은 JavaScript Object Notation으로 자바스크립트 객체 표기법입니다. 

JSON을 받은 JavaScript는 바로 페이지에 리렌더링해서 뿌려줄 수 있습니다. 즉, HTML을 계속 받아오는 것이 아니라, 그냥 JSON만 받아오면 되는 것입니다. 

즉, 

  • 페이지를 이동할 때마다 JavaScript로 인해 웹페이지의 DOM 구조가 바뀌며 리렌더링됩니다. (이때, HTML은 하나)
  • 서버와 통신을 해야할 경우, AJAX를 사용해야 하는데, 주로 axios를 사용합니다. 
  • 응답 값으로 데이터가 필요한 경우 JSON 형태로 데이터가 전송됩니다. 

무조건 SPA를 쓰는 게 좋을까? 

SPA도 물론 단점이 있습니다. 

서버가 할일을 대신하는 JavaScript의 역할이 막중해졌습니다. 규모가 커질수록 파일도 더 커지겠죠. 이를 해결하기 위해 코드 스플리팅을 사용하기도 합니다. 

또, JavaScript를 실행하지 않는 일반 크롤러에서는 페이지의 정보를 제대로 수집할 수 없습니다. 구글 검색 엔진의 경우, 크롤러가 JavaScript를 실행해주는 기능이 있지만 이 역시도 모든 페이지에서 해주는 것이 아니라고 합니다. 다른 검색 엔진의 경우는 JavaScript를 실행하지 않는 경우가 많기 때문에, 기껏 열심히 SPA로 페이지를 만들어놓았는데, 사람들에게 제대로 보여지지 않을 수 있습니다. (이럴 때, SPA에서 SSR을 사용합니다)

그리고 JavaScript 실행 전까지는 페이지가 비어있기 때문에 흰 화면 또는 로딩창이 나올 수 있습니다. 이 역시도 SSR(Server Side Rendering)을 통해 해결 가능합니다.  

*근데, HTML이 하나인데 페이지 이동이 어떻게 가능하죠?

이런 질문이 떠오를 수도 있겠네요. 예를 들면 localhost:3000에서 localhost:3000/write로 이동하는 경우, 페이지는 HTML 하나이지만, 라우터(다른 주소에 다른 화면을 보여줌)를 사용하면 JavaScript만으로 HTML 파일 내용을 바꿔줄 수 있습니다. 

 

*참고자료 

velog.io/@skypedanny/NextJS-%EA%B7%B8%EA%B2%8C-%EB%AD%94%EB%8D%B0?openLinerExtension=true  

medium.com/%EC%95%84%EB%AA%BD%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4/csr-ssr-spa-mpa-ede7b55c5f6f?openLinerExtension=true 

velog.io/@pkbird/Single-Page-Application?openLinerExtension=true