Feat: 챌린지 랜덤 기능 구현

[hee9841]

🔗 이슈 연결

• 오늘의 챌린지 랜덤 조회 #290

🚀 구현한 API

• X

💡 반영할 내용 및 변경 사항 요약

• 사용자의 어제의 러닝 기록 유무에 따라 챌린지 리스트를 다르게 조회합니다.
• 조회한 리스트를 오늘의 날짜(자정)의 값을 seed로 설정하고 리스트를 shuffle합니다.
• shuffle한 리스트의 인덱스가 0,1인 값을 리턴합니다.

🔍 리뷰 요청/참고 사항

• key 값으로 (날짜 + 어제 러닝 기록 유무)로해서 캐시사용하는 것 어떻게 생각하시나요? 자정에 캐시를 갱신하도록 하고, 사용자가 챌린지 값을 요청할 때 사용자가 어제 러닝 기록 유무만 확인하고 캐싱하는 것 어떻게 생각하시나요?? 굳이 캐싱이 필요할까 싶기도 하는데 재원님은 어떻게 생각하시나요?
• 만약 캐시를 적용하게 된다면 우선 해당 pr 머지하고, 적용하는 것으로 진행하면 좋을 것 같습니다.
• 그리고 지금은 챌린지 데이터가 적어서 Collections.shuffle을 사용했는데 추후 데이터가 늘어날 가능성이 적긴하지만, 데이터가 많아 진다면 성능 이슈가 발생할 것 같아서 추후 이 부분도 좀 고민해봐야 될 것 같아요!

[Jaewon-pro]

수고하셨습니다 👍

key 값으로 (날짜 + 어제 러닝 기록 유무)로해서 캐시사용하는 것 어떻게 생각하시나요? 자정에 캐시를 갱신하도록 하고, 사용자가 챌린지 값을 요청할 때 사용자가 어제 러닝 기록 유무만 확인하고 캐싱하는 것 어떻게 생각하시나요??

자정에 캐시를 지우는게 좀 까다로울 수도 있을 것 같긴 해요!

스케줄링을 돌리거나 다른 방법이 있을 것 같은데 그렇게 막 좋은 방법은 안 떠오르네용

그리고 지금은 챌린지 데이터가 적어서 Collections.shuffle을 사용했는데 추후 데이터가 늘어날 가능성이 적긴하지만, 데이터가 많아 진다면 성능 이슈가 발생할 것 같아서 추후 이 부분도 좀 고민해봐야 될 것 같아요!

챌린지가 엄청 많아지면 Collections.shuffle 대신 조회 시 LIMIT으로 개수를 제한할 수도 있을 것 같아요!