Feat #202 파트별 게시판 스터디 목록 조회 api 구현 #202
Conversation
| AND p.studyName IS NOT NULL | ||
| ORDER BY p.studyName ASC | ||
| """) | ||
| List<String> findDistinctStudyNamesByPart(@Param("part") Part part); |
There was a problem hiding this comment.
해당 내용은 아래 시현님 코멘트와 다르게, ALL 태그로 검색하는거 자체가 정상적이지 않은 상황이라 생각했어서
초기에 구현했을땐 빈배열로 반환해주는게 맞다고 생각했었어요 (추가적인 분기처리 없이)
근데 저희가 전체 스터디 게시판도 존재하니까, ALL 태그로 검색하는 경우에는 파트 구분없이 전체 스터디 이름을 반환해주도록 쿼리문을 수정해주는게 맞다고 판단이 드네용
hyxklee
left a comment
hyxklee
left a comment
There was a problem hiding this comment.
구현 고생하셨습니당
해당 유저가 진행한 기수에만 해당하는 결과물이 잘 보이게 구현된 것 같아요
유저가 특정 기수를 필터링하는 경우에도 본인이 진행한 기수의 자료만 보이게 구현 된거죠??
파트를 명시적으로 받는 경우는 전체 세션에서 나온 교육자료도 존재할 거라서 함께 볼 수 있도록 해주는게 좋을 것 같긴해요 대신 교육자료 게시판에 들어갔을 때 유저의 파트를 인식해서 해당 파트를 먼저 보여준다거나 하는 식으로 플로우를 확장할 수 있을 것 같습니당
| public record PartPostDTO( | ||
| @NotNull Part part, | ||
| Category category, | ||
| @NotNull Category category, | ||
| Integer cardinalNumber, | ||
| Integer week, | ||
| String studyName |
There was a problem hiding this comment.
검색용도라는게 어떤거 말씀하시는걸까요 ? 조회할때 request에서 사용되는 DTO입니다
분리한 이유를 물으신게 맞다면, @ModelAttribute 어노테이션에서 사용되는 dto라서 따로 분리해주었습니다
| return PostDTO.ResponseStudyNames.builder() | ||
| .studyNames(names) | ||
| .build(); |
There was a problem hiding this comment.
dto의 필드가 1개밖에 없기 때문에 useCase에서 빌더 패턴을 쓴건가요?
There was a problem hiding this comment.
아 이걸 못 봣네 객체 생성은 다 매퍼로 책임을 옮겨주새뇨
| @Query(""" | ||
| SELECT DISTINCT p.studyName | ||
| FROM Post p | ||
| WHERE p.part = :part | ||
| AND p.studyName IS NOT NULL | ||
| ORDER BY p.studyName ASC | ||
| """) | ||
| List<String> findDistinctStudyNamesByPart(@Param("part") Part part); |
There was a problem hiding this comment.
조회할 때마다 스터디 이름을 중복없이 가져오는게 게시글이 많아질 경우 성능 저하가 우려되네요
There was a problem hiding this comment.
저희 weeth 서비스는 캐싱이나 QueryDSL 기능들이 도입되어있지 않은 것으로 알고있었어서, 더 좋은 방식이 있을까요 ??
There was a problem hiding this comment.
크게 문제될 정도의 데이터가 쌓이진 않을 것 같아욤 후에 이슈가 생기면 수정해도 될 정도 같습니다
| import leets.weeth.domain.board.domain.entity.enums.Part; | ||
|
|
||
| public record PartPostDTO( | ||
| @NotNull Part part, |
There was a problem hiding this comment.
위 강혁님 코멘트 내용이랑 비슷한 내용인거같은데, ALL 일때는 전체 파트에 해당하는 내용이 반환이됩니다
BE, FE, PM, D
위 4개의 파트가 모두 포함됨
PR 내용
PR 세부사항
파트별 스터디 목록 조회 API 구현
파라미터로
part를 입력받아서 현재 생성되어있는 게시글 중에 스터디 이름들을 리스트로 반환해주는 API파트 게시판 조회시
ALL태그로 조회 로직 변경요구사항 맞춰서 카테고리 무조건 입력받도록, ALL 태그는 전체 조회로 수정
교육자료 게시판 조회시 조회 로직 변경
기존 교육자료 조회 로직 = 파라미터가 없으면 현재(최신) 기수 1개만 조회
-> 변경된 교육자료 조회 로직 = 파라미터가 없으면 유저가 속했던 모든 기수(ex: 5기, 6기)를 조회
관련 스크린샷
주의사항
교육자료 조회시 파트를 명시적으로 입력받는게 맞는가라는 의문이 들었어요
사실 백엔드면 교육자료에 들어가서 전체 교육자료를 볼 필요가 없이, 백엔드 교육자료만 자동으로 필터링해서 (서버단에서 조회) 반환해주는게 유저 경험 측면에서도 좋고 (응답이 몇개 없기때문) 로직상으로도 깔끔하다라는 생각이 들었습니다
해당 부분 같이 얘기해보고, 내일 전체 회의떄 같이 얘기해봐도 좋을거같아요 (해당 부분 뺴고는 다 요구사항 맞춰서 구현이 완료됐습니다)
체크 리스트