모임 일정 시간 조회 - 페이징 처리

[f1v3-dev]

🛠️ 어떤 기능인가요?

현재 상황

300개가 넘는 데이터를 한 번에 가져오는 상황

default.mov

요청에 대한 응답 시간

위 사진처럼, 모임 일정 시간 조회 API 는 데이터를 한 번에 조회를 진행하는 쿼리로 되어있습니다.

별도의 페이징 처리 없이 응답을 하기 때문에

1. 응답 시간이 현재 약 700ms 이며,
2. 클라이언트 화면에서도 스크롤이 많아져 불편함 을 느끼고 있습니다.

이러한 문제를 해결하고자, 페이징 처리 기법을 도입하려고 하며, 그 중 무한 스크롤 방식으로 구현하려고 합니다.

추가 사항

스프링에서 제공하는 Page 객체를 사용할 경우, 불필요한 응답값이 존재할 수 있습니다.
따라서, 커스텀 페이징 응답 객체를 별도로 만드는게 좋아보입니다.

🗒️ 작업 상세 내용

• 커스텀 페이징 응답 객체 생성 (제네릭을 사용해서 ResponseDto 사용하도록)
• 모임 일정 시간 조회 응답 - 페이징 처리

[f1v3-dev]

문제가 될 것 같은 점

1. A 회원이 모임 일정 시간 조회 페이지에서 스크롤을 내리고 있는 상황
2. B 회원이 일정 시간을 입력함
3. 조회하고 있던 A 회원에게 데이터가 이상하게 보여질 것 같음

[f1v3-dev]

대응 방향

커서 기반 페이지네이션이 적당해보임
하지만, 다른 커서 기반 페이지네이션 같은 경우 ID 값을 통해서 진행하는 것 같은데 우리의 데이터에는 ID 값이 없음..

시간을 잘 활용해보면 되지 않을까?

[RTUnu12]

해결 방안

• API 요청 시간(최초 호출)과 Schedule의 생성 시간을 비교하여, API 요청시간보다 생성 시간이 이후인 Schedule은 불러오지 않는다.

구현 방법

1. Schedule에 생성 시간(createdAt) 칼럼을 만든다.
2. 페이지네이션 최초 호출 시 그 호출 시간을 같이 전달한다.
3. 최초 호출할 때와 페이지네이션의 페이지를 넘어갈 때 다음에 올 Schedule의 생성 시간을 API 최초 호출 시간과 비교한다.
4. Schedule 생성 시간 > API 최초 호출 시간일 경우 호출 이후에 중간에 생성된 것이기에 조회 목록에서 제외한다.
5. 이를 반복한다. 만약 API를 다시 호출 시 최초 호출 시간 또한 변경되기에 Schedule의 변경 사항을 불러올 수 있다.

문제점

• 위 방법은 Schedule이 중간에 새로 생성되었을 때 유효하다. 즉 중간의 어느 Schedule이 삭제되었을 때에는 반영을 하지 못한다. (단 이 경우에 중복 조회는 발생하지 않는다.)

[f1v3-dev]

TODO

1. 일정(Schedule) Entity 필드 추가 - 할당된 시간?
2. 일정 시간 조회 요청 시점 기준으로 이전에 입력된 데이터만 조회하도록
3. 응답에도 요청 시점 을 클라이언트에게 넘겨, Query String으로 넘겨주라고 요청
4. 10개씩 짤라서 페이징 처리하기!