[Steady] 스테디 게시물 조회 첫 페이지 캐싱 처리

[weonest]

✅ PR 체크리스트

• 테스트
• 문서화 작업

💡 어떤 작업을 하셨나요?

Issue Number : close #195

작업 내용

• Steady 필터링 조회 방식 No-offset 기반임에도 페이징을 사용할 수 있도록 이전 페이지에 대한 커서 정보 적용
• CaffeineCache 를 이용한 페이징 조회 결과 캐싱 처리

📝리뷰어에게

1. Cursor 생성 방식에 대한 고민
   이전에 커서 방식 페이징으로 변경하면서 구현했던 커서 생성 방식에서 무언가 부족함이 느껴졌고, 이번 PR을 진행하면서 Cursor 클래스의 생성 방식을 리팩토링하였습니다. 기존에는 여러 분기로 나뉘어 있던 생성 코드를 생성자 팩토리 메서드로 어떤 동작을 하는지 보다 한눈에 파악이 가능하도록 변경하였습니다. 이외에도 전략 패턴, 팩토리 클래스 패턴 등을 생각해보았는데 어떤 방식을 적용해야 좀 더 나은 구조가 될지 잘 모르겠어서 리뷰어 분들의 의견을 들어보고 싶습니다.
2. DynamicQueryUtils 의 orderBySort 메서드에 대한 고민
   이번에 No-offset 기반임에도 이전 페이지에 대한 정보를 가져올 수 있도록 해당 메서드에 대한 리팩토링도 진행하였는데, 기존과 모두 동일하지만 정렬 방향만 반대로 바꿔야 하는 메서드가 필요하게 되었습니다. 이를 위해 파라미터를 추가하자니, 해당 메서드를 사용하는 다른 곳으로 변경 사항이 전파가 되기 때문에 새로이 reverseOrderBySort 라는 메서드를 만들었는데 의견 남겨주시면 감사하겠습니다.
3. PrevCursor 에 대한 고민
   이전 페이지 커서에 대한 정보를 담아주는 객체입니다. 평소에는 이전 페이지에 대한 커서 정보 (ex. promoted_at (LocalDateTime) 또는 deadline (LocalDate) 를 담아주게 되는데, 첫 페이지의 경우에는 이전 커서에 대한 정보가 필요 없기 때문에 우선은 null을 담아주도록 하였습니다. 임의의 값을 넣기에는 애초에 활용되지 않으면 좋겠다고 생각하여 이렇게 하였는데, 더 나은 방식이 있다면 의견 남겨주시면 감사하겠습니다.
4. PageResponse 생성에 대한 고민
   위의 1번 고민과 비슷한 내용의 고민입니다. 커서 정보의 자료형이 끌어올린 순으로 조회되었느냐, 마감임박 순으로 조회되었냐에 따라 LocalDateTime 또는 LocalDate 로 변동되는 상황입니다. 이를 서비스 코드에서 확인하기 위한 분기가 발생하고 분기에 맞는 PageResponse를 생성자 팩토리 메서드로 호출하는 식으로 구현하였는데, 이렇게 분기가 생기는 부분이 객체지향적이지 못하다고 생각되어 고민 중에 있습니다.

[github-actions]

Test Results

 27 files   27 suites   8s ⏱️
127 tests 127 ✅ 0 💤 0 ❌
128 runs  128 ✅ 0 💤 0 ❌

Results for commit 08e5bc9.

♻️ This comment has been updated with latest results.