논의 사항
거리기반 vs 행정구역
- 둘이 공존이 가능할까?
- 거리 기반으로 검색을 하는 것과 행정 구역별로 조회하는 것은 공존 할 수 없을 것같습니다. 둘중 하나는 지워야 될 것같아요
- 행정 구역을 선택한다면 ERD, 비즈니스 로직 변경이 일어납니다.
- 디자인과 UI 시퀀스도 달라질듯
사용자는 대결 상대와의 채팅방을 찾기 위해 채팅방 목록을 조회할 수 있다.
기존 API 설계 정보


- 기능 2가지
- 매칭에 대한 신청 목록(채팅 목록) 조회
- 작성자 입장에서 매칭 상세 화면에서 채팅 목록을 갔을 때,
- 신청자 입장에서는 매칭 상세 화면으로 갔을 때 바로 채팅방으로 들어가는 건지? (채팅 내용들을 볼 수 있는 화면)
- 네비게이션 바를 통해서 신청자 작성자 상관없이 모든 채팅방(신청 목록) 조회

- 논쟁점 2가지
- 2가지 기능을 API 하나로 할 것인지, 엔드 포인트를 나눌 것인지
- API 하나로 사용하는 경우
- 엔드 포인트를 나누는 경우
/api/matches/{id}/proposals?matchId=?
: 매칭 기준 조회/api/matches/proposals
: 사용자 채팅방 조회
/api/matches/proposals?matchId=?
- 문의 사항
- 사용자 채팅방 조회를 할 때, 어떤 경기에 대한 정보인지가 채팅방 목록에 없는데, 아래의 디자인과는 별도로 가는 걸까요?
⇒ 논의

NULL 생각정리
신청자가 채팅 목록 버튼을 누르면?
- 채팅 창에 바로 ㄱ
- UX적으로 편하다.
- 매치 ID에 해당하는 내 채팅 한개만 보여주기 그걸 누르고 채팅창에 들어감
- UX 적으로 조금 불편할 수 있다.
공고 작성자가 채팅목록 버튼을 누르면?
- 매치에 해당하는 모든 채팅 목록 조회
- /api/match/proposal?matchId:{}
네비게이션 바에서 채팅을 누르면?

- 내가 참여한 모든 채팅들을 조회 (어떤 매치건 상관없이)
- /api/matches/proposals
둘다 내 채팅을 불러오는데 어떤 match인지 아니면 matchID가 상관없이 불러오는 것
권한 같은경우에는 원래 있는거고(내 채팅을 불러오니까)`````
where절에 matchID 있고 없고 차이 아닌가?
데모 발표 준비 프론트에서 누가 하시겠어요?
톰슨으로 확정