[항해99 6기] 실전프로젝트 2주차 - 느낀점

2주차 실전프로젝트

 

느낀점

2주차에는 1주차에서 만들었던 API설계를 대부분 완성하는 일을 하였습니다.
프론트엔드와 디자이너 분들이 디자인 소통을 하면서, 

유저들의 편의성과 디자인을 이야기 해보았습니다.

사용자들이

"젊은 사람과 주부들이 신뢰를 갖고 이용할 수 있는 똑똑한 물물교환 서비스" 를

만들고자 API를 수정을 하였습니다.

1. N : 1 물물교환
대표적으로 N : M 다대다 교환이아니라, 

"상대방의 1개의 물품을 교환하기 위해서" 내가 가지고 있는 물품 여러개(N)를 교환하는
N : 1 물물교환으로 하기로 하였습니다.

 

2. 교환완료와 평가완료
또한 제품의 교환완료와 평과완료를 단방향이 아닌 양방향으로 결정하고, 

 

3. 평가점수 관리
당근마켓과 같이

자신의 활동을 차근차근 쌓아갈 수 있는 평가서비스를 하고자 하였습니다.

초기에 설정한 내용들이 바뀌면서,

 

채팅과 실시간알람기능 웹소켓, CICD 무중단 배포 등 구현하는데

집중하지 못했던 점이 아쉬웠던 것 같습니다.

 

하지만 감사하게도 석준님과 승재님이 채팅과 웹소켓을 맡아주셔서

이번 3주차는 많은 도움을 받을 예정입니다.

 

-> 내가 구현할 기능 : 실시간 알람기능

-> 거래신청과 평과완료 등 웹소켓을 통해서 사용자에게 메시지를 전달하는 기능

 

2주차에서 내가 한일

1. 마이페이지 - 찜목록 3개만 보여주기 수정
2. 교환내역페이지 - 거래상태에 따른 전달 형식 수정 EX) 거래중: DATE(거래내역의 수정시간)을 보내주지 않음 / 거래완료 & 평가완료 : DATE (거래내역의 수정시간)을 보내 줌
3. 거래내역 조회 성능 개선 시도 (JPQL의 @QUERY)

-마이페이지)

3개의 테이블을 INNER JOIN으로 연관관계 맺음

거래내역)

거래내역(Barter)에 파싱 되어있는 아이템 리스트를 (”1,2,3 ; 10”)

Item List들을 @Query를 사용하여 한번에 조회하고자 하였습니다.

하지만 Item 테이블에 에 거래내역(BarterId)에 대한 정보가 없기 때문에 거래내역 별로 구분해서 조회할 수 없었음

    4. 교환신청 취소와 수락 API 추가

    5. 평가하기 점수

    6. 14일차 : 상대방 평가 ( 채팅 10분 이내 응답시 보너스를 주는 로직 짜보기)

 

-> SQL 실행계획? -> EXPLAN을 붙여서 SQL의 쿼리의 실행 속도를 확인 할 수 있음 

https://huisam.tistory.com/entry/mysql-plan-query

Mysql Query Plan - Intellij 를 활용하여 Plan query 를 해보자

-> 하지만 JPA findByBuyerIdOrSellerId(userId, userId) 와같은 것은 성능을 확인할 수 없음

https://jeong-pro.tistory.com/170

3가지만 기억하자. 스프링 부트 초간단 캐시 @EnableCaching, @Cacheable, @CacheEvict (spring boot cache example)

-> 캐시로 성능 체크? 공부할 예정

 

 

https://goguming2.tistory.com/87

[항해99 6기] 실전프로젝트 2주차 - 상대방 평가