문제 발생
상품 상세 페이지 조회를 짜던 팀원이 좋아요 여부를 Long likeMemberId 로 넘기는 코드를 보았다.
또한 상세페이지 한번에 10개의 쿼리문이 나가는 현상을 발견해서 다른 팀원이 issue로 올렸다.
바로 물어 보았다.
Coodori: 혹시 likeMemberId 용도가 뭘까요??
A : 아 좋아요 누른 사람의 아이디를 넣은거에요! , 프론트에서 현재의 memberId 값과 이 memberId를 비교해서 좋아요를 하게 하려고합니다.
여기서 생각이 든게
1. 해당 게시물을 좋아요 누른 사람은 여러명이고 현재 fetchFirst()로 받아오기 때문에 리스트 형태로 id 가 반환되지 않는 이상 해당 로직을 사용할 수 가 없다.
2. 이분사건및 여부를 보여주는 것이 목표인데 id 값을 넘겨서 주는 것보단 boolean 처리를 하여 좋아요를 눌렀는지 안눌렀는지 판단하는 것이 좋을 듯 하다.
3. 쿼리 최적화가 필요할듯하다. n+1 문제
문제 해결
현재 유틸 어노테이션으로 @CurrentUser을 만들어 놓았다.
해당 유틸 어노테이션은 Jwt 를 인증한 후 인증이 되면 Member가 담기게 되고 아니면 null이 담기게 된다.
해당은 A 팀원이 합류하기전에 만든 유틸어노테이션이라 인지를 못하고 있어 인증된 사용자와 인증되지 않은 사용자의 처리를 고민하다가 코드가 너무 길어질듯하여 해당 현재 방법을 사용했다고 한다.
아무튼 1번과 2번 현재 유틸 어노테이션으로 분기 처리가 되어있으니 비교를 하여 boolean으로 돌려주면 해당 좋아요 여부는 해결완료!
3번 같은 경우 현재 url을 "brand","coupang","naver","kakao" 이렇게 전달을 해주게 되었는데 해당을 각각 파싱해서 찾다보니 url 찾을 때 쿼리가 4개씩 날라가는 현상이였다.
또한 해당 방법은 NPE가 발생할 가능성이 매우컸다.
(데이터를 넣을때 다 넣어준게 아니다보니깐....)
그래서 최종 response에 각 4개의 항목을 파싱한 값을 FE에게 전달해주었는데 나는 해당 방법이 비효율적이라고 생각해 코드 리뷰를 달았다.
저때는 말을 제대로 못했는데
1. 4개의 항목을 전부 주고 싶으면 빈 플랫폼은 null처리를 한다.
2. null값을 받기 싫어하면 그냥 우리가 조회한 리스트로 바로 준다.
3. 현재 방식을 사용하고 싶으면 get 대신 getOrDefault를 사용하여 값을 무조건 넣어준다.
(이후 set할때 NPE를 방지하기 위해)
라고 생각해서 피드백을 하였다.
2번이 제일 맞는 방법이라고는 생각한다.
단지 주면 react의 map 함수로 url 처리만 해주면 되니깐!
결론
해당 방법으로 쿼리가 줄어들었고 팀원의 코드 리뷰를 함께하여 batch_fetch_size 등을 통해 10개에서 4개로 줄였다.
하지만 batch_fetch_size는 다양한 일대다 조인상황에서 유리한것 같고
url 부분을 하나로 줄이고 싶은데 조금 더 고민을 해서 줄여보고 해결이 되면 적어보려고한다.
현재 문제를 느끼기에
1. spring data jpa로 재 검색하는 로직이 문제인 것 같고
2. @OnetoMany를 join을 해줬다는것도 문제인 것 같다.
내일 한번 다시 문제를 찾아봐야겠다.
오늘의 코드리뷰와 하루 피드백은 여기까지!
