[항해99 6기] 실전프로젝트 - 업무 방향성 업데이트

1. 업무 방향성 변경

석준님 : JWT작업 & 소셜로그인 구현(카카오) 완료 -> 웹소켓 (채팅기능 & 알람기능)

승재님 : 상품등록, 이미지 등록 등 전반적인 CRUD 완료 -> 웹소켓 (채팅기능 & 알람기능)

나 : 마이페이지, 거래내역 조회, 찜 목록 조회 CRUD -> 웹소켓개념 -> SQL & 리팩토링

승재님을 도와서 웹소켓을 구현하고자 하였지만, 웹소켓에 대한 이해가 부족하여

DB자료 조회시 최적화 할 수 있는 방법을 알아보는 방향으로 변경하기로 하였습니다.

2. 기술멘토링 내용

이주호 기술 멘토님과의 멘토링내용 (14:30 - 15:00)

1) ERD 설계를 직접 해보니 최적화에 문제점이 많아 보입니다. 테이블 수정을 해도 괜찮을까요?

하나의 칼럼만을 사용해 구분자로 정보를 넣어 놓은 것은 나쁜 생각은 아닙니다.

다만, 구분자가 너무 많습니다. 거래 내역 테이블을 살펴봤을 때 두 번이나 구분자로 나누어 놓았습니다.

이렇게 하면 서버에서 많은 연산이 일어날 것입니다.

또한, 파싱된 각 Index에 대한 정보를 찾기 위해서는 DB에서 추가적인 조회를 해줘야 하겠죠?

테이블을 하나 더 설계합시다.

PK를 두 개 준비하세요. 테이블에서 정보를 나누어 가져오는 것이 좋아 보입니다.

또한, 구분자에 대한 파싱을 서버에서 직접 해 줄 필요가 없습니다.

Native SQL로 DB에서 가져올 때 처리가 가능하니, 이 부분을 공부해 보세요.

테이블이 설계된 이후에 수정을 하는 것이 일반적으로는 좋지 않습니다.

그러나, 수정이 불가피할 수 있어요.

이 경우에는 되도록이면 원본을 변형하지 않는 선에서 진행해 주셔야 합니다.

현재 index를 최대한 활용하는 방식으로 테이블을 만들어 주셨습니다.

그러나 경우에 따라 index 대신 JOIN하여 연관관계 맵핑을 하는 수정은 가능합니다.

앞서 드렸던 조언처럼 테이블을 하나 추가하는 것도 좋은 예시가 됩니다.

또한, 쿼리가 남발된다면 페이징 처리도 고려해 보셔야 합니다.

다양한 방법으로 최적화를 시도해 보세요!

2) 2주차까지 최대한 기본기능을 완성한 이후에 3주차부터는 본격적으로

리팩토링과 추가기능 구현에 들어가려고 합니다. 현재 스코프를 봤을 때 가능할까요?

구현 혹은 수정하려고 하는 기능이 무엇인가요?

실시간 알림 기능이나 알림톡 기능인가요?

데이터베이스 리팩토링인가요?

그렇다면 가능합니다.

3) (백엔드) 확인해본 결과,

Http Response Status가 200 ~ 300번대가 아닌 경우이면서

동시에 Body에 Json 파일을 실어야 하는 경우에 대한 문제입니다.

프론트측이 백엔드가 전달해준 body를 읽기 위해서는,

axios 혹은 ajax로 받은 응답값에 대해 error로 처리해야한다고 알고 있습니다.

현재 백엔드에서는 프론트측의 error 처리에 대한 부담을 줄이기 위해 모든

JSON 형식의 예외처리 응답을 status 200 Ok로 전달하고 있습니다. 이렇게 해도 괜찮을까요?

200 OK 응답으로 일괄 처리하시는 것 보다는, HttpStatus를 커스터마이징하시고,

코드에 대해서도 서로 약속하셔서 응답값을 내려주시는 것이 좋다고 생각됩니다.

치명적인 오류라면 프론트 측에서도

어디에서 문제가 생긴 것인지 응답값을 통해 판단할 수 있어야 할 것 같습니다.

4) 좋아요 기능에 대한 질문입니다.

참조자료들을 찾아본 결과, 좋아요 기능을 PUT 방식으로 업데이트 하는 방법이 있고

POST 방식으로 insert 했다가 DELETE 하는 방법이 있습니다.

블로그별로 제시하는 방법이 다릅니다. 어떤 것이 더 좋은 선택일까요?

PUT 방식으로 업데이트 하는 것이 나아 보입니다.

테이블에 업데이트 플래그를 추가하세요.

DB에 insert를 하는 것은 update에 비해 상대적으로 비용이 더 큽니다.

5) DB최적화에 관한 질문입니다.

DB를 검색하는 방법 중 GetBy와 findBy가 있습니다.

GetBy 방식은 제가 알기로는 DB에 접촉을 최소화하여 프록시를 가져오는 방법입니다.

백엔드의 Service 계층에서 발생하는 많은 연산 중,

findBy를 통해 직접 객체를 생성하지 않아도 무방한 경우도 있습니다.

예를 들어, 단순 회원 중복확인과 같은 경우입니다.

이런 경우에는 GetBy를 사용해도 무방할까요?

상황에 따라 무방합니다. 그러나 getBy가 어떤 방식인지는 확실히 공부해 보세요.

... 실무에서는 생성 객체를 어떻게든 사용하는 경우가 많기 때문에

GetBy 방식을 사용하는 경우가 드물어요. :)

6) 이번에는 제가 여러분에게 질문을 드리겠습니다. 와이어 프레임을 살펴봤을 때

'n건의 알림이 도착했습니다' 라는 메시지를 메인 뷰에서 표기해 주고 있습니다.

이 기능은 뷰가 전환 될 때마다 서버로 API 요청을 보내는 방법을 사용해 구현할 것인가요?

아니면 웹소켓을 사용해 구현할 것인가요?

뷰를 전환할 때마다 API 요청을 보내어 알림 건수를 계산해 오는 방식을 채택하시게 된다면,

메인 페이지에 부하가 걸릴 수 있어요.

웹소켓을 이용하실 거라면 반드시 레디스를 사용하지 않아도 좋습니다.

7) 프로퍼티를 이용해 주세요.

예를 들어 이미지 파일의 주소를 칼럼으로 저장하실 때

반복되는 부분은 프로퍼티에 할당하고 꺼내어 쓰시는 방법을 고려해 보셔야 합니다.

3. 디자인님과 회의

15:00 - 17:00 까지 디자인담당이신 다은님과 다은님과 회의를 하였습니다.

주로 이야기 나눈 내용은 디자인 방향성과 납기기간에 대한 이야기였습니다.

5/06(금) 오후 9시 : 메인페이지 디자인을 포함해 4개이상 페이지에 디자인을 입힌 와이어프레임
5/13(금) 오후 9시 : 디자인 포함 전체 와이어프레임

전체 디자인 최종 수정 데드라인 : 5월 10일(화요일)

-> 프론트엔드의 작업시간을 고려하여

11일 수요일에서 하루 앞당긴 10일로 변경하였습니다.

4. 추가된 API

ㄱ. 마이페이지와 회원정보 수정

ㄴ. 나의 교환내역조회 ( 교환중 & 교환완료 )

<거래중인 내역 API>

<거래완료된 내역 API>

ㄷ. 교환평가( 평가방법 ABCDF -> 5,4,3,2,1으로 변경 )

<평가하기 조회 & 평가하기 API>

5. 거래내역의 거래상태 추가

<거래중인 내역보기 - status : 0일경우 >

status : 0 -> 거래중

[
    {
        "barterId": 1,
        "date": "2022-04-27T18:58:24.429",
        "myItem": [
            {
                "itemId": 1,
                "title": "1번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            },
            {
                "itemId": 2,
                "title": "1번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            }
        ],
        "barterItem": [
            {
                "itemId": 10,
                "title": "3번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            }
        ]
    }
]

<거래완료된 내역보기 - status : 1 / 2일경우 >

status : 1 -> 거래완료

status : 2 -> 평가완료

평가를 완료하면 status를 1 -> 2으로 업데이트를 해준다.

[
    {
        "barterId": 2,
        "date": "2022-04-27T18:58:24.429",
        "myItem": [
            {
                "itemId": 3,
                "title": "1번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            },
            {
                "itemId": 4,
                "title": "1번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            }
        ],
        "barterItem": [
            {
                "itemId": 9,
                "title": "3번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            }
        ],
        "graded": false
    },
    {
        "barterId": 3,
        "date": "2022-04-27T18:58:24.429",
        "myItem": [
            {
                "itemId": 5,
                "title": "1번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            }
        ],
        "barterItem": [
            {
                "itemId": 6,
                "title": "2번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            },
            {
                "itemId": 7,
                "title": "2",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            },
            {
                "itemId": 8,
                "title": "2번",
                "itemImg": "ㅁㄴㅇㄹ",
                "date": "2022-04-27T18:58:24.429",
                "status": "qwer"
            }
        ],
        "graded": true
    }
]

'일기 > 항해99' 카테고리의 다른 글

[항해99 6기] 실전프로젝트 2주차 - 상대방 평가 (0)	2022.05.07
[항해99 6기] 실전프로젝트 1주차 느낀점 (0)	2022.05.01
[항해99 6기] 실전프로젝트 - 예외성 검사 & 새로운 문제 (0)	2022.04.29
[항해99 6기] 실전프로젝트 - 코딩실수 (0)	2022.04.29
[항해99 6기] 실전프로젝트 API설계하기 (0)	2022.04.24