[Spring] SSR, CSR HTTP API 이용한 렌더링 방식의 차이점

서비스를 제공하기 위한 방식의 고민 과정을 정리

• SSR 방식의 리소스 제공 방식
• CSR 방식의 리소스 제공 방식
• 어쩌면 CSR과 비슷한 HTTP API 제공 방식

 

렌더링은 서버에 요청한 데이터를 브라우저 화면에 보여주는 것이다.

 

SSR - 서버 사이드 렌더링

 

• 서버에서 클라이언트의 페이지 내용을 완전히 그려내어 브라우저에 전달해준다
• 클라이언트에서 페이지를 이동할 때마다 새로운 페이지를 요청해야한다

 

장점

• 초기 로딩 시간이 빠르고 검색 엔진 최적화에 유리하다
• 렌더링 자체를 서버에서 끝내서 클라이언트에 전달하기 때문에 페이지 생성 시간을 단축 시킬 수 있다.

단점 

• 페이지 전환시 전체 페이지를 로딩하기 때문에 페이지 요청마다 새로고침이 발생하기에 동적 상호작용이 많은 경우 성능이 떨어진다는 문제가 있다
• 서버에서 렌더링을 진행하므로 서버 부하가 발생한다

 

CSR - 클라이언트 사이드 렌더링

 

• 처음 요청시 하나의 페이지만 호출한다
• 요청한 페이지에서 사용자의 요청에 따라 필요한 부분을 개별적으로 다시 읽어와 렌더링한다

 

장점

• 사용자의 동적 상호작용이 많은 경우 전체 페이지를 새로 로드할 필요 없이 데이터를 변경이 가능하다

단점

• 초기 렌더링 시간이 느려 검색 엔진 최적화 문제가 발생한다
• 클라이언트에서 페이지를 그리기에 처음 화면을 그려 사용자에게 제공하는 시간이 길어진다 

 

HTTP API 방식

 

• 클라이언트가 서버에 데이터 요청을 하고, 서버는 필요한 데이터만 JSON 형태로 클라이언트에게 응답합니다.
• 클라이언트는 받은 데이터를 기반으로 페이지 또는 페이지의 일부를 렌더링합니다.
• 데이터가 필요할 때마다 API 요청을 보내고, 서버는 데이터만 반환합니다.

장점

• 클라이언트와 서버의 역할이 분리되어 있으며, 클라이언트는 필요한 데이터만 요청하여 렌더링합니다.

단점

• 클라이언트와 서버 간의 통신이 빈번하게 이루어져야 하며, 네트워크 지연이 성능에 영향을 줄 수 있습니다.

 

각 방식의 차이점

 

• SSR vs CSR: SSR은 서버에서 HTML을 완전히 렌더링하여 클라이언트에 전송하는 반면, CSR은 클라이언트에서 JavaScript를 통해 페이지를 렌더링합니다.
• SSR/CSR vs HTTP API: SSR과 CSR은 페이지 렌더링 방식에 초점을 맞추는 반면, HTTP API 방식은 데이터 통신에 중점을 둡니다. SSR과 CSR은 페이지의 전체적인 렌더링을 처리하는 반면, HTTP API는 데이터를 제공하는 역할에 집중합니다.

 

	서버에서 페이지 완전 렌더링	클라이언트에서 페이지 동적 생성	서버에서 데이터만 응답
SSR	O	X	X
CSR	X	O	X
HTTP API	X	X	O

 

 

각각의 구현 방식마다의 차이점과 이점이 존재하기에 서비스 플렛폼의 목적에 따라 선택하는게 좋을거 같다. SSR 방식으로 제공되는 서비스에 HTTP API를 이용한 모바일 환경에도 서비스를 제공하는 코드를 작성해야되는 일이 생겨 SSR 방식과 HTTP API를 분리 구현을 할지 하나의 Controller에 통합 구현을 해볼지 고민을 했었다. 각각의 방식의 차이점을 정리하다보니 명확하게 정리해 구현 방식을 선택할 수 있었다. 당연하게도 SSR, HTTP API는 목적 자체가 다르기에 분리 구현을 진행할 예정이다.