📝 TIL

[TIL] 5주차 주특기 심화ㅣ게시글 좋아요 API

오늘 ONEUL 2022. 12. 12. 22:37

 

주특기 심화 주간 과제

팀 협업 방향

팀원 모두 Lv1까지 개인적으로 구현을 완료했고,
오늘부터 Lv2를 함께 작업하기로 했다.
Lv2의 요구사항은 게시글, 댓글 좋아요 API, 예외처리이다.

 

 

과제에서 요구하는 시점에 가장 가까운 조원분의 프로젝트를 바탕으로
최대한 각자가 해보지 못한 부분을 맡아 협업을 진행하기로 결정!
나는 게시글 좋아요 API를 맡게 되었다.

협업에는 Git 사용이 필수적이기 때문에
프로젝트 진행 전, Git과 Github을 통한 소스코드의 병합이 어떻게 이루어지는지 연습해보는 시간을 가졌다.
Git-flow 브랜치 전략을 최대한 가져가되, 우리 프로젝트 규모에 맞게 [main-develop-feature]만 적용해보기로 했다.
나도 완벽히 안다고 할 순 없지만 최대한 내가 아는 선에서 조원분들에게
커밋 컨벤션, 이슈 사용방법, 기능 개발 진행 순서 등을 알려드리고 나니
조원분들이 너무 유익했다고 해주셔서😁 뿌듯 뿌듯!

 

📚 Git-flow 참고자료

 

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합

techblog.woowahan.com

 

개인 과제 진행 상황

팀 과제와는 별개로 나는 Lv2까지의 과제를 개인적으로도 도전해볼 생각이다.
그래서 게시글 좋아요 API를 개인 과제에 먼저 적용시켜 보려 한다.

 

 

 

오늘의 궁금증

 

게시글 좋아요 개수를 어떻게 출력하면 좋을까?

게시글 좋아요 API를 구현하는 데에는 다음과 같은 것들이 필요하다.

  1. 유저가 좋아요를 누르면 '좋아요 완료', 다시 누르면 '좋아요 취소'
  2. 해당 게시글이 좋아요를 받은 개수 출력
  3. 로그인한 회원이 해당 게시글에 좋아요를 했는지 여부 판별

이 중 1번과 3번은 비교적 쉽게 구현했는데 2번은 구현 방법이 여러 개 떠올라 어떤 것이 더 효율적 일지 고민이 되었다.
내가 생각한 좋아요 개수를 출력하는 방법 3가지는 다음과 같다.

좋아요 개수를 출력하는 3가지 방법

1) '게시글'과 '게시글 좋아요'를 다대일 양방향으로 매핑 후, 게시글에 포함된 게시글 좋아요 List의 size를 출력
2) '게시글'과 '게시글 좋아요'를 다대일 단방향으로 매핑 후, 게시글을 조회할 때마다 게시글 좋아요 Repository에서 count를 구하는 쿼리 메소드를 통해 개수 출력
3) '게시글'과 '게시글 좋아요'를 다대일 단방향으로 매핑 후, 게시글 쪽에 좋아요 개수를 출력할 필드를 만들고 좋아요 요청이 있을 때마다 해당 필드를 업데이트하여 출력

일단 나는 연관관계를 단방향으로 매핑했기 때문에 3번 방법을 통해 게시글 좋아요 개수 출력을 구현했다.
구현 후 Postman을 통한 테스트는 다음과 같이 진행했다.

간략한 테스트 시나리오

  • 한번 누르면 좋아요 완료, 한번 더 누르면 좋아요 취소
  • 좋아요가 취소되면 게시글 좋아요 개수의 카운트도 -1
  • 전체 조회할 때 좋아요 개수, 해당 회원의 좋아요 여부 반환
  • 상세 조회할 때 좋아요 개수, 해당 회원의 좋아요 여부 반환

모든 테스트 통과!
하지만 궁금했다. 과연 이게 최선의 방법일까?
이후 기술 매니저님께 어떤 방법이 더 효율적 일지 조언을 구하였다.

일단 3번째 방법은 데이터의 무결성을 생각하면 좋은 방법이 아니라고 하셨다.
또, 1번과 2번은 내부적으로는 비슷한 방법이라고도 말씀해주셨다.

다시 생각해보니 게시글과 게시글 좋아요처럼 밀접한 관계를 맺고 있는 엔티티는 양방향으로 매핑하는 것이 더 알맞을 것 같다.
기술 매니저님의 조언에 따라 1번의 방법으로 로직을 변경할 예정!

 

📚 참고자료

 

(JPA) JPA @Id GenerationType.AUTO, IDENTITY 차이

JPA @Id @GeneratedValue(strategy = GenerationType.AUTO) @GeneratedValue(strategy = GenerationType.IDENTITY) 차이 테스트용 Entity @Data @Entity @Table(name = "ex_entity") public class ExEntity { @Id @Column(name = "id") @GeneratedValue(strategy = Gene

lion-king.tistory.com

 

 

AUTO vs IDENTITY

JPA를 통해 기본키(PK)를 매핑하는 전략에는 2가지가 있다.

@Getter
@Entity
@NoArgsConstructor
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    
    ...
}
  • AUTO : id 생성을 위해 hibernate_sequence 테이블의 시퀀스 값을 가져와 업데이트하고, 그 값으로 id를 생성하여 insert 쿼리를 사용한다. 모든 기본키를 AUTO로 설정해놓으면 존재하는 모든 테이블이 hibernate_sequence 테이블을 공유하여 겹치지 않는, 고유한 id를 생성하게 된다. 이 설정은 default로 아무것도 적지 않으면 AUTO로 동작한다.

 

@Getter
@Entity
@NoArgsConstructor
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    ...
}
  • IDENTITY : insert 쿼리가 pk 값 없이 수행된다. 데이터베이스의 auto_increment 동작이 수행된다. [ddl-auto: create]을 사용 중이라면 pk 옵션이 auto_increment로 생성된다. 각 테이블마다 고유한 id를 생성하게 된다.

 

 

 

오늘의 나는

체감상 아무것도 해낸 일 없이 하루가 가버린 것 같았는데
막상 적고 보니 오늘도 꽤나 호기심 가득한 하루를 보낸 듯싶다.

함께 하는 일도 너무 중요하지만,
개인적으로 해야 하는 일들이 뒷받침되었을 때 더 큰 시너지 효과가 난다고 생각한다.
그런 시간들을 조절하는 게 참 쉽지가 않다.

해보지 못한 일에 과감히 도전하고, 자주 실패하기!
그 안에서 분명 얻는 게 많을 것!