설명
일반 웹 어플리케이션
- 일반적인 웹 애플리케이션은 URL이 변경됨에 따라 서버에서 html을 매번 받아와서 렌더링을 하게 됨
- 레이아웃에 대한 것도 thymeleaf나 이런 것들 이용해서 서버쪽에서 처리 함. 여러 html 파일 합쳐서 렌더링 처리하는 부분도 서버에서
단일 페이지 웹 어플리케이션
- 단일페이지 웹 어플리케이션 — url 변경시 특정 영역만 렌더링 됨. DOM조작을 통해서 렌더링이 이루어지게됨 → 클라이언트 개발 부담, 렌더링. 고객의 pc 자원을 활용 하기에, 서버에서는 이점을 볼 수 있음
- 프론트와 백엔드 구분이 더 명확해짐.서버에서 thymeleaf나 이런 것들 통해서 신경 안써도 되니
시간 흐름에 따른 페이지 로딩절차 비교
일반적인 웹 페이지
- HTTP 요청이 stateless 이기에 필요한 개념이 세션. 첫번째 요청과 두 번째 요청 사이에 유지하고 싶은 상태(예를 들어 로그인) 이런 것이 HTTP 만으로는 안 되니까
- 사용자가 웹 서비스에 머문 일정시간 동안 유지되는 상태 — 세션
- 로그인을 하게 되면 해당 세션에 사용자의 이메일이나 계정 정보 같은 것이 세션에 보관됨
- 그 다음 요청이 해당 사용자의 요청이라는 것을 알기 위해서 쿠키(세션ID를 계속 실어서 보내는)를 사용
- 사용자가 로그인을 하면 서버에서는 쿠키를 발급해 주고 브라우저에서 아무 처리 안해줘도 요청에 쿠키 실어서 보냄. 그럼 해당 세션에서 사용자 데이터 모델 찾아서 그 사용자(예를 들어 customerId같은)로 비즈니스 로직을 처리하게 됨
- 세션에 메뉴 정보, 사용자 configuration 등의 정보를 세션에 계속 넣게 되면 세션이 커지게 됨 → SPA 기반에서는 브라우저에서도 일부 들고 있게 되는 것
SPA
- 브라우저의 local storage(클라이언트 쪽의 persistence layer같은) 에 사용자 데이터 모델의 일부를 담아 놓음
- local storage의 데이터 모델 일부를 통해서 처리를 할 수 있음. 매번 페이지 요청할 필요 없이 변경이 되어야할 때만 데이터 요청을 함(Dom manipulation, AJAX)
- 일반적으로 DOM을 바꾼다고 해서 url이 바뀌지는 않음
라우팅 처리
- html에서 특정한 어떤 부분 클릭 하면 다른 페이지로 넘어가게 하는 것을 서버쪽에서 진행을 했던 것
클라이언트 라우팅 처리
- 여기서 만약에 DOM만 바꾸고 요청 다시하면(새로고침) url이 바뀌지 않았기 때문에 처음의 페이지 그대로 다시 나오게 될 것임
- HTML5 히스토리 API나 #(해쉬) 또는 $!(해쉬뱅) 처리를 이용해서 URL을 변경시킬 수 있음(javascript이용해서 클라이언트에서 처리하는 것)
- 리액트를 이용하면 리액트 <Router> 태그로 명시해주면 내부적으로 알아서 javascript가 HTML5 히스토리 api를 이용해서 url을 변경해주는 것임
- 이렇게 되면 서버에서는 뷰를 반환하는 건 전혀 없어짐. Json이나 XML을 반환하게 됨