Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Refactor] 모임 일정 시간 페이징 처리 및 베스트 타임 API #126

Merged
merged 9 commits into from
Oct 1, 2024

Conversation

f1v3-dev
Copy link
Member

@f1v3-dev f1v3-dev commented Sep 30, 2024

#️⃣ 연관된 이슈

resolves #121, resolves #123

📝 작업 내용

  1. 모임 일정 시간 조회 - 페이징 처리
  2. 모임 일정 시간 중 베스트 타임 (우선순위) 조회 API 구현

💬 리뷰 요구사항

@f1v3-dev f1v3-dev added the refactor 리팩토링 label Sep 30, 2024
@f1v3-dev f1v3-dev self-assigned this Sep 30, 2024
Comment on lines +12 to +16
@Getter
public class PagedResponse<T> {

private final T data;
private final PageInfo pageInfo;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

굳이 PageInfo를 객체로 놔두는 이유를 알 수 있을까요?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

클라이언트 측 응답 JSON 형태가 data를 담는 부분 / page 정보를 담는 부분 두가지 영역으로 나뉘었으면 좋겠어서 이렇게 구분을 하는게 낫지 않을까? 라고 생각을 했어요!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

아하 알겠습니다. 유지보수가 더 쉬워질 듯 하네요.

Comment on lines +142 to +143
.where(meeting.meetingUuid.eq(uuid)
.and(schedule.assignedAt.loe(requestTime)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PathVariable("meetingUuid") String uuid,
@RequestParam(value = "sort", defaultValue = "COUNT") MeetingSort sort) {
@PageableDefault(sort = "count") Pageable pageable,
@RequestParam(value = "request_time", required = false) String requestTime) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이 부분은 프론트에서 API 최초 요청 시간을 보내는 건가요?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

엇 네 맞습니다.

시나리오를 생각해보면,

  1. 프론트에서 첫 페이지 요청을 함. (request_time은 빼고)
  2. 서버에서 응답시, 응답 필드에 requestTime 을 추가하여 프론트가 요청한 시간을 보내줌
  3. 이후 프론트에서 다음 페이지 요청시, request_time 정보를 함께 서버로 요청함
  4. 서버에서는 요청 시간을 기준으로 이전에 저장된 일정 데이터만을 조회함. (일정 할당 시간 <= 요청 시간)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

그러면 API의 최초 요청 시간은 파라미터에 request_time를 빼고 전송할 때 갱신되는건가요?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

네 맞아요! 그 부분을 조금 주의해서 요청을 해야해요

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

아하 알겠습니다. 머지하셔도 될 것 같습니다.

@RTUnu12
Copy link
Collaborator

RTUnu12 commented Oct 1, 2024

리뷰 확인 부탁드립니다.

@f1v3-dev f1v3-dev merged commit b7b4902 into develop Oct 1, 2024
@f1v3-dev f1v3-dev deleted the refactor/#121-meeting branch October 1, 2024 09:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor 리팩토링
Projects
None yet
Development

Successfully merging this pull request may close these issues.

모임 메인 페이지 - 최적의 시간(1개) API 모임 일정 시간 조회 - 페이징 처리
2 participants