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

느낀점

 

이번 주는 목표한 MVP를 완성과 중간발표가 있었던 한 주 였습니다.

 

MVP완성 목표는 웹소켓을 이용한 채팅과 알람기능 구현과 HTTPS와 CI/CD 무중단 배포 구현이였습니다.

 

1. 원래는 실시간 알람기능을 제가 구현하기로 했지만, 부끄럽게도 웹소켓부분을 아직 잘 다루지 못하였고

 

2. 저번 주 기술 멘토링에서 JPQL의 @QUERY어노테이의 성능을 테스를 위해서 먼저

ㄱ. 인텔리제이에 내장되어있는 MySQL 콜솔에 쿼리문의 속도를 확인 할 수 있는 기능을 사용해보았습니다.

EXPLAIN SELECT * FROM employee_table;

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

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

 

=> JPA문으로 사용되는 FindById 와같은 것들을 테스트할 수 없어서

JPA와 JPQL의 전체적인 성능 테스트에 부적합하다고 판단하엿습니다.

 

ㄴ. 전 기수 선배들이 성능테스트로 JMETER를 많이 사용하여서, 적용해 보았습니다.

-> 마이페이지를 조회를 할 때 100명이 1초당 10번 요청했을 경우로 테스트를 해보았을 때 3~4초의 응답시간이 발생하였습니다.

-> 거래내역과 같은 경우에는 14초정도로 응답시간이 심각하게 느려지는 것을 알 수 있었다.

 

https://goguming2.tistory.com/89

JMeter 공부하기 - 1

https://goguming2.tistory.com/91

Jmeter사용해보기 - 마이페이지 조회

 

다양한 방법으로 쿼리요청을 했지만, 큰 성능 개선은 발생하지 않았다.

또한 똑같은 조회를 반복했을 경우 점점 빠르게 조회하는 현상을 확인하였는데,

신뢰 가능한 테스트가 무었일까? 라는 의문을 갖게 되었다.

+ Query문으로 조건문 없이 조회했을 때 일반 JPA문보다 성능이 나빠지는 것을 확인 할 수 있었다.

 

ㄷ. QueryDSL 공부하기

전 기수 선배들이 QueryDSL이라는 라이브러리를 통해서 성능개선을 하였다고 해서, 공부를 하고있습니다.

다만 그래들에 설정해야되는 부분이 조금 복잡해서, 강의를 따라잡기는 어려웠지만

현재 TEST코드를 통해서 DSL문을 익히고 있습니다.

현재는 추가적인 기능구현에 몰입하기 위해서 잠시 멈췄지만, 5주차 쯤에 구현할 수 있지 않을까 생각됩니다.

 

 

https://velog.io/@youngerjesus/%EC%9A%B0%EC%95%84%ED%95%9C-%ED%98%95%EC%A0%9C%EB%93%A4%EC%9D%98-Querydsl-%ED%99%9C%EC%9A%A9%EB%B2%95

우아한 형제들의 Querydsl 사용법

https://goguming2.tistory.com/90

QueryDSL 공부하기 - 1

https://goguming2.tistory.com/94

QueryDSL 공부하기 - 4 ( DTO조회 )

 

중간발표 백엔드 피드백내용

 

1. 유저신고 기능을 추가하는게 좋을것 같습니다.
- 채팅의 특정단어를 필터링해서 경고를 주는 형식으로 추가기능을 해주시면 좋을 것 같습니다.
(백엔드 3분이 하시기에는 API가 부족하다는 느낌이 듭니다.)2. 이미지를 원본과 썸네일을 따로 관리하면 좋을 것 같습니다.3. 파일 디렉토리를 기능별로 분류를 하는 것이 좋을 것 같습니다.4. API 패스 이름을 간단하게 변경하면 좋을 것 같습니다.
예시 1 )
/myhistory -> barters
예시 2 )
 showMyBarter5. 거래내역 모델을 리스트형식으로 저장하기
자료가 이상한 형식으로 올 수 있기 때문에 리스트 형식으로 저장하기
-> size로 체크를해서검증한뒤 이름은 s만 붙여 주시면 될 것 같습니다.
(split ","가 없을 수 있기 때문)

 

<느낌?>

-> 다른조에 비해서 백엔드 피드백이 적었다,

-> 1. 반복되는 피드백 때문인지, 언급할 내용이 별로 없어서인지

-> 2. 프로젝트가 와 닿지 않았다는 느낌을 받았습니다.

 

<승재님이 녹화하신 5조 중간 발표영상>

https://youtu.be/8NgE4FjiPxo

 

기술매니저님과의 멘토링

 

1. QueryDSL -> ERD 잘되어있으니 잘 적용해서 할 수 있을 듯
2. 속도를 내야됨 -> 기능을 먼저 구현하고, 최적화를 하시는 방향
3. 예외처리 핸들러 -> 코드 / 메시지 해당오류를 담아서 보내주기?

 

 

 

내가한 일

 

팀원들에게 죄송하게도 이번주에는 제가 추가적으로 구현한 API나 기술은 거의 없었습니다.

 

금요일 -> 토요일까지 웹소켓을 공부했지만 프로젝트에 어떻게 적용해야 될지 몰라서 석준님이 구현해주셨습니다.

(정말... 죄송합니다 ㅠㅠ)

 

토요일 저녁부터 JMETER를 통해서 조회테스트를 하였고

 

월요일, 화요일 에는 QueryDSL을 공부하였습니다.

 

이후 수요일 - 금요일까지

승재님은 HTTPS와 CI/CD, 서버쪽을 맡아주시고,

 

저는 단순히 API를 수정하는 부분만 했던 것 같습니다. (거래내역 조회와  수정과 평가하기)

ㄱ. 거래내역 조회는

기존에 ( DTO - (거래중, 거래완료)DTO - 내용 ) 구조에서

 

한번에 보내주되,

Barter의 상태에 myPosition, isTrade, isScore, status 4가지로 거래정보를 한번에 보내주는 구조로 수정하였습니다.

 

[
 {
     ”barterId”:1,
     ”userId”:5, ← 상대방 아이디,
     ”usernickname”:”상대방 닉네임”
     ”Profile”: “상대 이미지”,
     ”date”:”거래일시”,
     ”status”:2,
     ”myPosition”:”buyer/seller”
     ”isTrade” : false
     ”isScore” :  false 
     ”myItem”:
           [
           {
           ”itemId”:1,
           ”title”:”배게팝니다”,
           ”image”:”대표이미지”,
           },
           {
           ”itemId”:2,
           ”title”:”구슬팝니다”,
           ”image”:”대표이미지”,
           }
           ],
     ”baterItem”: ←상대물품 1개
          [
          {
          ”itemId”:4,
          ”title”:”어떤거 사요”,
          ”image”:”대표이미지”,
          “contents” :”내용내용”
          }
          ]
     },
 {
     ”barterId”:1,
     ”userId”:5, ← 상대방 아이디,
     ”usernickname”:”상대방 닉네임”
     ”Profile”: “상대 이미지”,
     ”date”:”거래완료일 때”,
     ”status”:2,
     ”myPosition”:”buyer/seller”
     ”isScore” :  true
     ”myItem”:
           [
           {
           ”itemId”:1,
           ”title”:”배게팝니다”,
           ”image”:”대표이미지”,
           },
           {
           ”itemId”:2,
           ”title”:”구슬팝니다”,
           ”image”:”대표이미지”,
           }
           ],
     ”baterItem”: ←상대물품 1개
          [
          {
          ”itemId”:4,
          ”title”:”어떤거 사요”,
          ”image”:”대표이미지”,
           “contents” :”내용내용”
          }
          ]
     }
]

 

ㄴ. 평가하기

 

보너스점수에 대해서 프론트와 논의하지 않고, 로직의 틀만 잡는다는 느낌으로 만들어놨었던 부분이

프론트 쪽에서 굉장이 싫어하는 말씀을 하셔서, 조금 당황했던 것 같습니다.

 

발표를 앞두고 민감해지고, 많이 바빠서 (HTTPS와 API에 맞추는 작업의 비중이 커서) 이야기를 드리기 힘들었었는데

앞으로는 바쁘더라도 이런 방향으로 만들어 보겠다는 언질이라도 드리는 방향으로 해야겠다고 생각됩니다.

 

이 부분은 일단 구현만 가능하도록 전체점수에 +- 되는 부분만 구현하고,

보너스를 주는 코드는 전부 주석처리하였습니다.

 

 

 

내가 해야하는 일

 

팀 목표는 아래와 같이 우선순위를 정하였습니다. 

< 프론트 >

1. CSS -> 날짜 정해서 확정 필요

2. 채팅방 무한스크롤

3. HTTPS 적용< 공통 >

4. API 패스 변경( )

< 백엔드 >

5. 스프링 캐시 적용하기

6. 채팅 필터링, 게시물 신고 기능

7. 알림기능 완성( 실시간 교환, 메인페이지로 실시간 요청 전달 )

 

5번은 석준님6번은 승재님7번은 본인이런 식으로 구현하기로 정해졌는데,

 

3주째 웹소켓에 쩔쩔매는 저자신이 부끄럽고 이것밖에 할 수없나? 하는 생각이 들었지만

석준님의 강력한 부탁으로 어떻게되는 자신감은 없지만 어떻게든 구현하기로 약속하였습니다.

 

https://daddyprogrammer.org/post/4077/spring-websocket-chatting/

Spring websocket chatting server(1) - basic websocket server

 

위 사이트를 통해서 채팅방을 만들고, 들어가서 메시지를 주고 받는 부분을 실습해 보기는 했지만,

이 것을 어떻게 변형해서 작동테스트를 하는가에 대해서 감이 안잡히고 있는 상황입니다.

 

우선은 석준님이 만들어 두신 알람기능을 활용하여 다음과 같은 조건일 때 알람이 저장되는 것으로 변형을 했지만,

예제에 적용할려면 현 SERVICE에서 JWT 토큰으로 주어져야 하기 때문에,

어떻게 테스트를 해야될 지 고민해야 되는 부분입니다.

 

< 받아온 토큰의 내용 >
JwtAuthFilter: null

 

테스트를 위한 접근방법이 무었이 있을까?

1. 예제에 헤더에 토큰을 담아서 보내는 방법이 있을까? (JWT를 잘 몰라서 기각...?)

2. 파일을 백업해서 서비스에 USER값을 임의로 넣어서(토큰 삭제?)

JWT를 사용하지 않고 보내줄 수 있는 코드로 변형해볼까?

-> 이 방향으로 한 번 구현해 볼까..? / 석준님은 어떻게 구현했지? ㅠㅠㅠ

 

if (myPosition.equals("buyer")){
    // 알림 내역 저장 후 상대방에게 전송
    Notification notification = notificationRepository.save(Notification.createOf(myBarter, user.getNickname()));

    messagingTemplate.convertAndSend(
            "/sub/notification/" + myBarter.getSellerId(), NotificationDto.createFrom(notification)
    );
} else {
    // 알림 내역 저장 후 상대방에게 전송
    Notification notification = notificationRepository.save(Notification.createOf2(myBarter, user.getNickname()));

    messagingTemplate.convertAndSend(
            "/sub/notification/" + myBarter.getSellerId(), NotificationDto.createFrom(notification)
    );
}