-
Notifications
You must be signed in to change notification settings - Fork 4
06 ‐ 07 ‐ 쪽지 모듈
Ryu(Paul) edited this page Nov 9, 2023
·
1 revision
- 비즈니스 요구사항
- 아키텍처 설계
- API 엔드포인트 설계
- 다른 모듈과 상호작용 포인트
- 사용자 간의 1대 1로 쪽지를 주고 받는 REST 기능을 구현한다.
- 사용자는 쪽지를 보낼 수 있다.
- 사용자는 받은 쪽지를 확인할 수 있다. 쪽지 페이지에 접근 시, API 호출시 항상 최신의 메시지를 확인이 가능하다.
- 사용자는 받은 쪽지 리스트를 삭제 할 수 있다. 단, 쪽지 개별로 삭제는 지원하지 않으며 상대방과의 대화 목록 자체의 삭제만을 지원한다.
- 사용자는 쪽지를 받을 수 있고, 받을 시 알람이 갈 수 있어야 한다(PWA로)(2차 스텝)
- 자기 팀의 사용자들의 목록에 빠르게 접근 가능하다 (2차 스텝)
- 자기 팀의 사용자들의 목록에 접근한 이후, 선택을 통해 메시지를 전달한다.(2차 스텝)
- 클라이언트의 요청에 따라 쪽지 리스트를 전달한다(무한 스크롤)
- 친구 목록도 많아지면 최대 개수만큼 보여주고 난 뒤에는 요청시 추가로 불러온다.
- 비동기 구현을 통해 동시 처리 1000명 이상을 달성할 수 있게 만들어 내야 한다.
- Controller : HTTP 요청을 처리한다.
- Service : 비즈니스 로직 수행
- MessageIndexRepository : 메시지 목록을 가리키는 레포지터리
- MessagePieceRepository : 실제 메시지가 저장되는 레포지터리
(ERD 참고할 것)
- messageIndex
- conversationId : 대화 고유 키
- userId1 : 쪽지 대상 1
- userId2 : 쪽지 대상 2
- unreadMessageNumber1 : 읽지 않은 메시지 1
- unreadMessageNumber2 : 읽지 않은 메시지 2
- messagePiece
- msgId : 메시지 고유 키
- senderId : 송신자 Id
- senderNickname : 송신자 닉네임
- messageTime : 보내온 시간
- readTime : 상대방이 읽은 시간
- text : 내용
- conversationId : 대화 고유 키(외래키로 활용)
- 쪽지를 요청하고, 정확하게 받았는가에 대한 처리가 필요하지 않을까?
- 실제로 읽지 않고 눌러보기만 했는데, 읽은 것으로 처리를 바꾸는 것이 옳을까?(짧은시간 접속에 대한 처리가 필요하지 않을까)
- 대화목록을 정렬하는 알고리즘이 필요하다. 새로운 메시지를 읽지 않은 숫자가 기준이 되어서 정렬이 필요하다. 그리고난 뒤 데이터가 들어올 텐데, 그럼에도 해당 순서를 유지되어야 할 텐데 어떻게 가능한가? 백엔드에서 이를 처리하는 구조를 했을 때 충분한 성능이 나올 것인가?
- 쪽지 대상 리스트 요청
- 쪽지 삭제
- 새 쪽지 창에서, 닉네임 검색하기
- 새 쪽지 창에서, 메시지 전달하기
- 특정 쪽지 목록 보기
- 특정 쪽지 목록에서 답하기
- 특정 쪽지 목록에서 무한 스크롤 요청하기
- 상대방 프로필 탐색 메소드 필요
- 팀 참여자 ID 탐색 메소드 필요
- 알림 DB 쪽으로 쪽지 내용을 전달하기 위한 메소드 필요