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

[FEAT] 무한스크롤의 중복 컨텐츠 문제 해결 #192

Merged
merged 7 commits into from
Oct 1, 2024

Conversation

jaewonLeeKOR
Copy link
Member

@jaewonLeeKOR jaewonLeeKOR commented Sep 29, 2024

PR 타입(하나 이상의 PR 타입을 선택해주세요)

  • 기능 추가
  • 기능 삭제
  • 버그 수정
  • 의존성, 환경 변수, 빌드 관련 코드 업데이트

반영 브랜치

feat/#190/infiniteScrollDuplicateContent -> develop

변경 사항

  • 무한스크롤을 이용한 컨텐츠 로드 시에 기존의 컨텐츠를 화면에 유지하며 새로운 컨텐츠를 불러온다는 점에서 새로운 컨텐츠가 계속해서 생길 경우 중복 데이터를 불러온다는 문제점이 존재합니다.
  • 무한스크롤 API에서 조회 기준을 정하고 클라이언트에서 무한스크롤 시에는 기준을 유지하고 로드하여 중복 컨텐츠를 없앨 수 있습니다.
  • 모든 무한스크롤 API 에서 threshold(조회 기준)를 파라미터로 받는 방식으로 구현했습니다.
    • threshold를 비필수 파라미터로 지정하여 하위호환도 가능하도록 구현하였습니다.
  • 질문조회 API에서는 liveAt 기준으로 컨텐츠를 제한하기 위해 LocalDateTime 타입을, 그 외의 API에서는 id 기준으로 컨텐츠를 제한하기 위해 Long 타입으로 threshold 타입을 지정하여 케이스에 따라 다른 기준값을 사용하도록 했습니다.
    • threshold 는 Query Parameter 형식으로 받기 때문에 어떤 데이터타입을 사용하든 파싱이 잘되고 있음을 확인했습니다.

아래와 같이 데이터를 주고 받도록 프론트에 요구할 예정입니다.

sequenceDiagram
actor u as 사용자
participant c as iOS<br>device
participant s as 서버
u ->>+ c : Pull to Refresh<BR>OR<BR>First Load
c ->>+ s : 무한 스크롤 API<BR>threshold 미포함
s ->>- c : API 결과 반환<BR>threshold 포함
c ->> c : threshold 로컬 저장<BR>페이징 API 마다

u ->>+ c : Scroll
c ->>+ s : 무한 스크롤 API<BR>threshold 포함
s ->>- c : API 결과 반환<BR>threshold 포함
Loading

테스트 결과

답변
image
image
게시판 댓글
image
image
질문
image

개선 요망 사항

  • 좋아요 기반의 리스트 조회의 경우에는 좋아요에 대한 시각 또는 id를 저장하고 있지 않아서 그에 따른 적당한 threshold가 존재하지 않는것으로 판단됩니다.

@jaewonLeeKOR jaewonLeeKOR added the 🌟enhancement New feature or request label Sep 29, 2024
@jaewonLeeKOR jaewonLeeKOR self-assigned this Sep 29, 2024
@jaewonLeeKOR jaewonLeeKOR linked an issue Sep 29, 2024 that may be closed by this pull request
2 tasks
tnals2384
tnals2384 previously approved these changes Sep 29, 2024
Copy link
Contributor

@tnals2384 tnals2384 left a comment

Choose a reason for hiding this comment

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

LGTM 방식이 창의적이에요!!

youngeun-dev
youngeun-dev previously approved these changes Sep 29, 2024
Copy link
Contributor

@youngeun-dev youngeun-dev left a comment

Choose a reason for hiding this comment

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

굿굿굿 ~ 조회시각기준을 프론트가 잘 활용할 수 있도록 설명이 필요하겠네요 ,, !!!

@jaewonLeeKOR
Copy link
Member Author

지금 방식의 문제가 있어서 수정이 필요할거 같아요.
좋아요한 컨텐츠 조회

  • 직관적으로 생각해보면 좋아요한 시각을 기준으로 최신순으로 정렬이 되어야할거라고 생각이 되는데 지금은 컨텐츠의 생성 시각을 기준으로 정렬되고 있어요

createdAtid의 인덱싱 문제

  • 생성 시점을 기준으로 새로운 컨텐츠가 생겨도 Pull to Refresh를 하기 전까지는 같은 컨텐츠를 로드한다는 점은 같습니다. (몇 API를 제외)
  • 저희가 인덱싱 방법에 대한 다른 세팅을 하지 않았기 때문에 PK인 id가 인덱싱되어있을것으로 생각됩니다.
    • 따라서 id를 이용한 방법이 더 빠를것으로 예상됩니다.

index기반의 컨텐츠 고정 구현에서의 문제

  • 질문 같은 경우는 정확히 어떻게 질문의 상태 변화가 일어나고 있는지는 확인하지 못했지만, PK인 id와 live가 되는 시각의 순서가 달라지는 경우도있을거라 생각됩니다.
  • 좋아요 조회의 경우는 더 심각한게 index 기반이든 createdAt의 기반이든 최신의 데이터를 좋아요한 후 예전의 데이터를 좋아요하는 경우 기준이 좋아요에 있는것이 아니라 컨텐츠 자체에 있기 때문에 기존의 데이터 중복이 일어날것으로 보입니다.
    • 사용자가 하나의 클라이언트를 사용한다면 좋아요는 본인이 만드는 데이터이므로 당연히 한번에 두개의 뷰를 띄울 수 없기에 문제가 되지 않을것으로 보이긴 합니다.

마지막 인덱스(id)를 이용한 방법으로도 로컬상에서는 전환하여 구현 끝내놓은 상태입니다.
의견 남겨주세요..! @youngeun-dev @tnals2384 @kyxxgsoo

kyxxgsoo
kyxxgsoo previously approved these changes Sep 30, 2024
Copy link
Contributor

@kyxxgsoo kyxxgsoo left a comment

Choose a reason for hiding this comment

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

LGTM 👍

Signed-off-by: 이재원 <ghfkddl706@me.com>
Copy link
Contributor

@youngeun-dev youngeun-dev left a comment

Choose a reason for hiding this comment

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

LGTM 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🌟enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

무한스크롤 개선
4 participants