커서 페이징 최적화

[wonslee]

💡 Page가 아닌 Slice를 사용할 예정
이유: Page는 Slice를 상속받고, totalElements 필드를 따로 갖고 있음. 그런데 우리는 대부분의 API에서 커서 페이징을 사용하고 totalElements 필드 값을 필요로 하지 않음
필요하다면 따로 카운트 쿼리를 실행

❓아예 새로운 Response객체를 만들지 고민중(SliceResponse?)
클라이언트측에서 SliceRepsonse에 맞게 응답받는게 베스트라고 생각

[jinukeu]

혹시 API 응답값도 바뀌나요?

[wonslee]

혹시 API 응답값도 바뀌나요?

바뀔 예정이예요!
급한 기능 구현은 아니라서 진욱님 기능 구현 다 끝나신 뒤에 같이 크로스 체크해보고 merge하려고 합니다

이건 잘 몰라서, 미리 응답 객체를 만들어둬서 사용하시나요?
예를 들면 class ... Response { Long totalElements, boolean last, ...} 이런식으루요

만약 이게 맞다면
현재는 리스트 조회시 사용하는 응답 객체가 하나일거 같은데,
totalElements가 필요 없는 부분에선 totalElements가 없는 버전의 객체를 새로 만들고 교체하면 될거같습니다

[jinukeu]

혹시 API 응답값도 바뀌나요?

바뀔 예정이예요! 급한 기능 구현은 아니라서 진욱님 기능 구현 다 끝나신 뒤에 같이 크로스 체크해보고 merge하려고 합니다

이건 잘 몰라서, 미리 응답 객체를 만들어둬서 사용하시나요? 예를 들면 class ... Response { Long totalElements, boolean last, ...} 이런식으루요

만약 이게 맞다면 현재는 리스트 조회시 사용하는 응답 객체가 하나일거 같은데, totalElements가 필요 없는 부분에선 totalElements가 없는 버전의 객체를 새로 만들고 교체하면 될거같습니다

리스트 조회 관련 공통 Response 객체는 따로 안만들었어요!
조금 귀찮을 뿐 시간이 오래 걸리는 작업은 아니라 괜찮을 것 같네요~

[wonslee]

아하 글쿤요
알겠습니다!