CSR VS SSR

 

 

 

 

개인 프로젝트에서 Controller 반환값을

페이지 반환에서 JSON 반환으로 바꾸면서

그럼 페이지 반환은 어떻게 해줘야 할까 고민이 생겼어요😥

 

ViewResolver, ModelAndView, ResponseEntity에 대한 개념을 확립하고

ResponseEntity와 ModelAndView를 함께 사용하려 했는데

이게 맞는지 확신이 안들었어요

 

더 알아보다보니 CSR과 SSR 방식에 대해 알게 되었고

이참에 확실히 개념을 정리하고 싶어 포스팅하게 되었습니다 :)

 

---

CSR 방식

Client Side Rendering

초기 로드 시 빈 HTML과 모든 로직이 담겨있는 Javascript를 다운로드한다.

그 후 빈 HTML에 Javascript를 이용하여 Dom을 동적으로 생성하여 그려낸다.

위와 같이 클라이언트에서 렌더링한다고 하여 클라이언트 사이드 렌더링이다.

이 방식은 하나의 페이지로 이루어진 SPA에 적합하다.

SPA는 Vue, Angular, React 프레임워크로 만든 홈페이지들 대부분이 속한다.

 

장점

• 원하는 내용만 업데이트할 수 있다.

ex) 중복되는 Footer 같은 내용은 제외하고 바뀌는 내용만 업데이트할 수 있다.

 

단점

• 각 페이지에 대한 정보를 담기 힘들어 검색 엔진 최적화(SEO)에 취약하다.
• 첫 진입 시 Javascript 다운로드를 위해 로딩 시간이 긴 편이다.

 

 

SSR 방식

Server Side Rendering

서버에서 렌더링하여 완성된 HTML 파일을 로드한다.

클라이언트에서 요청할 때마다 각 상황에 맞는 HTML 파일을 넘겨주기 때문에 페이지가 여러 개이다.

그래서 이 방식은 페이지가 여러 개인 MPA에 적합하다.

 

장점

• CSR보다 초기 진입 속도가 빠르다
• CSR보다 SEO를 향상할 수 있다.
• 완성된 HTML로 화면에서 확인이 가능하다.

 

단점

• 새로운 HTML 파일을 서버에서 받아오기 때문에 화면 깜빡임 현상이 있다.
• Header, Footer처럼 중복되는 내용도 렌더링하기 때문에 페이지 이동이 비교적 느리다.
• Javascript 다운로드가 늦어지면 완성된 HTML을 화면으로 확인이 불가능한 경우도 있다.

 

---

Thymeleaf를 사용하면

HTML 및 XML 기반의 View 템플릿 엔진으로 사용되는 기술이다.

이 기술을 사용하면 서버측에서 실행되어 클라이언트에게 렌더링된 최종 HTML을 전송한다.

즉, SSR 방식을 사용하게 된다.

 

 

REST API를 사용하면

사용자가 원하는 페이지를 요청하고, 해당 페이지에 필요한 데이터를 프론트가 백에게 REST API 형태로 요청하고, 데이터 확인 후 백이 다시 프론트에게 REST API 형태로 전달한다.

 

---

 

CSR과 SSR, Thymeleaf와 REST API 각각 장단점이 있습니다.

그렇기에 무엇이 더 좋다라고 확답하기에는 어렵습니다.

프로젝트 환경 및 상황에 따라 유동적으로 사용해야 하는 것 같습니다.

 

하지만 REST API로 작성하면 외부에서 사용이 가능한 형식이라는 점이 있습니다.

그래서 저는 둘 다 사용하기로 했습니다! ㅎㅎ