항해99(7D) 3주 마지막날

Request

GET: DB 정보를 화면에 보여주고 싶을 때
POST: 입력한 정보를 DB에 보내주고 싶을 때
PUT: 특정 id에서 입력한 정보를 수정하고 싶을 때
PATCH: 특정 id에서 입력한 정보를 부분 수정하고 싶을 때
DELETE: DB의 데이터를 삭제하고 싶을 때

 

전체 게시글 목록 조회 API GET /api/posts List <Posts>
게시글 작성 API POST /api/posts Post Post
게시글 수정 API PUT /api/posts/{id} id, Post id
게시글 삭제 API DELETE /api/posts/{id} id
게시글 눌러보기 GET /api/posts/{id} Posts
검색어를 포함하는  게시글 목록 조회 API GET /api/search?query= String query List<ItemDto>

 

페이징 작업하기 전까지는 API 설계 한 대로 작업을 했었다. 페이징을 제외한 모든게 완료된 상태에서 페이징을 구현을 위해 thymeleaf를 통해 서버사이드 렌더링을 부분 사용했는데, templates에 index.html 페이지가 하나 밖에 없으니... 어찌저찌 페이징 구현을 했지만 전체 게시글 목록을 받아오는 GET request들이 문제가 생기기 시작했다.
이를 해결하고 완성이라 생각하고 제출 전 과제를 다시 한 번 확인해보니 비밀번호가 구현이 되어야한다고 적혀있어서 다시 코드를 뜯어고쳤다. View를 따로 구현을 안 하고 modal을 사용했던게 RESTful한 API를 설계하지 못한 원인이었던 것 같다. 아니면 페이징을 사용할 때 thymeleaf를 사용하지 말던가.  SSR CSR의 환상의 짬뽕이 되어서 index.html과 main.js 코드가 엄청 지저분해졌다..
다음 프로젝트에서는 MVC모델을 정확히 이해하고 SSR CSR의 구분을 명확히 해 좀더 괜찮은 코드를 만들고 싶다는 생각을 했다...

 

SPA(Single Page Application)

사용자가 한 페이지 내에 머무르면서 필요한 데이터만 서버에서 받아와 부분적으로 업데이트 된다. 이런 방식으로 하나의 어플리케이션을 사용하듯 웹 사이트에서도 앱과 같은 사용자 경험을 느끼게 되어 사용성이 굉장히 좋아지게 된다.

 

CSR(Client Side Rendering)

CSR은 쉽게 말해 모든 렌더링을 클라이언트 측(브라우저)에 위임하는 것을 의미한다.

1. 첫화면을 초기화하는데 오랜 시간이 걸린다 -> 첫화면이 보여지기까지 오래 걸린다.
2. 낮은 SEO(Search Engine Optimization) -> 검색엔진 최적화의 어려움, 낮은 검색 순위

• 색인이 비교적 중요하지 않은 경우
• 관리자 페이지나 사용자 경험이 중요한 카카오맵과 같은 웹 앱

색인 (Index) · 문서에서 키워드를 찾아 보기 쉽도록 정렬 및 나열한 목록.

-> 최종적으로 번들링해서 클라이언트에게 보내주는 JS파일을 어떻게 하면 효율적으로 분할해서 사용자가 첫화면을 볼 때 필수적인 것들만 보낼 수 있을지 고민

SSR(Server Side Rendering)

웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고 이렇게 만들어진 파일을 동적으로 제어할 수 있는 약간의 자바스크립트 소스 코드와 함께 클라이언트에게 보내준다. 

1. 사용자가 클릭을 하게 되면 전체적인 웹 페이지를 다시 서버에서 받아오는 것과 동일하기 때문에 CSR에 비해 좋지 않은 사용자 경험을 겪을 수 있다. 
2.  동적으로 데이터를 처리하는 자바스크립트 파일을 아직 다운로드 받지 못해서 클릭해도 반응이 없는식과 같은 사용자와의 상호작용을 하지 못할 수도 있다. 

• 검색 엔진의 색인이 필요한 경우
• 콘텐츠가 주를 이루는 뉴스나 강의 페이지 같은 경우

-> 사용자가 보고 상호작용 할 수 있는 이 시간의 차이를 줄일 수 있는 방법에 대해 고민하거나 어떻게 하면 매끄러운 UI/UX를 제공할 수 있을지 고민

CSR의 TTV(Time To View)와 TTI(Time To Interact)

먼저 CSR이 사용자에게 웹 사이트를 보여주기까지의 모든 과정을 시간 순서대로 나열해보자.

1. 클라이언트가 사이트에 접속한다
2. 서버에게서 index 파일을 받아온다 -> 텅텅 비어진 태그와 JS파일 링크 -> 빈화면
3. 해당 웹 앱에 필요한 모든 로직이 담긴 링크된 JS파일 요청 -> 빈화면
4. 동적으로 HTML을 생성할 수 있는 웹 앱 로직이 담긴 JS파일을 받아옴 -> 웹 사이트 노출, 상호작용

CSR은 4번부터 웹 사이트가 사용자에게 보여짐과 동시에 사용자와의 상호작용이 가능해진다.

 

즉 CSR은 TTV(Time To View)와 TTI(Time To Interact)가 동시에 이뤄진다.

SSR의 TTV와 TTI

이제 SSR의 과정을 시간 순서대로 나열해보자.

1. 클라이언트가 사이트에 접속한다
2. 서버에서 이미 잘 만들어진 index 파일을 받아온다 -> 웹 사이트 노출
3. 동적으로 제어할 수 있는 로직이 담긴 링크된 JS파일 요청 -> 웹 사이트 노출
4. 사용자와 상호작용이 가능한 JS 파일을 받아옴 -> 웹 사이트 노출, 상호작용

SSR은 2번부터 웹 사이트가 사용자에게 보여지지만 4번부터 사용자와의 상호작용이 가능해진다. 따라서 사용자가 웹 사이트를 볼 수 있는 시간과 상호작용 할 수 있는 공백 시간이 꽤 있는편이다.

즉 SSR은 TTV(Time To View)와 TTI(Time To Interact) 사이의 공백 시간이 존재한다.