[진웨이얀] 7주차 과제 제출#30
Conversation
RockScissors
left a comment
RockScissors
left a comment
There was a problem hiding this comment.
과제 수고 많으셨습니다!
크게 리뷰 남길 부분이 없었네요 😁😁 가볍게 읽어주세요!
| } | ||
|
|
||
| private void authorizeBoardOwner(Board board, Long memberId) { | ||
| if (!board.getMember().getMemberId().equals(memberId)) { |
| @RestController | ||
| @RequestMapping("/comments") | ||
| @RequiredArgsConstructor | ||
| public class CommentController { |
| @Getter | ||
| @Table(name = "post_likes") | ||
| @NoArgsConstructor(access = AccessLevel.PROTECTED) | ||
| public class PostLike { |
There was a problem hiding this comment.
새로 만든 PostLike 역시 BaseEntity를 상속받도록 해서 생성 시각, 마지막 수정 시각 필드를 갖도록 하면 좋을 것 같습니다!
| @RequestHeader("Auth-Id") Long memberId | ||
| ) { | ||
| postService.unlikePost(postId, memberId); | ||
| return ResponseEntity.ok("좋아요가 취소되었습니다."); |
There was a problem hiding this comment.
DELETE 계열 작업의 REST 관례는 204 No content 입니다! '작업은 성공했고, 돌려줄 데이터는 따로 없다'는 의미를 상태 코드가 담고 있기에 별도의 메시지 없이도 클라이언트가 의미를 파악할 수 있습니다.
다만 DELETE 이후 상태 정보를 응답으로 줘야 한다면(예시 - 팔로우 취소 후 '현재 팔로워 수'와 같은 값 반환) 200 ok + body를 사용합니다.
지금의 경우에는 취소 후 따로 돌려줄 결과값이 없으니 204를 사용하는 것도 좋을 것 같습니다!
return ResponseEntity.noContent().build()
return ResponseEntity.status(HttpStatus.NO_CONTENT).build()
| private Long viewCount; | ||
|
|
||
| @Column(nullable = false) | ||
| private Long likeCount; |
There was a problem hiding this comment.
게시글 좋아요 수를 PostLike 테이블의 레코드 수와 Post.likeCount 필드 두 곳에서 관리하고 있네요!
현재의 방식은 '읽기 비용을 아끼기 위해 쓰기 복잡도를 높이는' 방식인 만큼, 이 부분은 트레이드오프 영역에서 고민해보면 좋을 것 같아 덧붙여 봅니다. (수정을 요구하는 것은 아닙니다!)
현재 방식처럼 likeCount를 Post에 저장해두면 조회 시 Post 조회만으로 좋아요 수를 바로 가져올 수 있어 효율적입니다. 트래픽이 큰 서비스에서는 이런 식의 반정규화를 많이 사용하기도 합니다.
다만 반대로, 지금과 같은 구조에서는 PostLike 데이터와 Post.likeCount 값이 항상 동일해야 한다는 책임을 애플리케이션 코드가 직접 관리하게 됩니다. 그래서 좋아요 추가/취소 시 count 증가/감소 누락 가능성, 동시성 처리, 다른 경로에서 데이터 수정 시 정합성 문제와 같은 가능성이 생기게 됩니다. 반면 countByPost()처럼 실시간 집계 방식을 사용하면 읽기 비용은 조금 더 들 수 있지만, 데이터의 source가 PostLike 하나로 유지되기에 더 단순하고 안전할 수 있습니다.
답이 있다기보다는, 조회 트래픽이 크고 목록 조회가 매우 빈번한 경우 -> 현재와 같은 방식을, 규모가 아직 크지 않거나 단순성이 더 중요하다면 -> 실시간 count query 가 더 적절하다고 볼 수 있습니다.
현재 서비스 규모와 요구사항에서 어떤 트레이드오프를 가져갈지 고민해보면 좋을 것 같습니다!
2 participants
📌 구현 기능
🗂️ 과제 정리
참고