241111 회의록

오늘 할 일

• 2주차에서 오류난 부분 잡기
• 좌석 배치도 관련 논의
  • 어떻게 저장할지
  • DB에 어떻게 반영하고, 제공할지
  • API 명세서에 반영하기
• SSE 관련 API 명세서 수정
• 메인 페이지 변경 관련 API 명세서 수정
• 목 데이터 제공 API 필요성 논의
• 각 이슈의 INPUT 상태 / OUTPUT 상태 정하기
• SSE 실습

코드 리뷰 진행 방법 수정

• approve 룰(현재 2명이 approve해야 머지 가능)을 수정해야하지 않을까? ⇒ 현재 0명으로 변경!!!

  • 너무 개발의 효율성이 떨어진다.
  • 실제 approve할 때 코드리뷰를 꼼꼼하게 하지 않는다.

• 새롭게 그룹 회고 시간 혹은 금요일 저녁에 따로 시간을 투자해 코드리뷰 혹은 기술 공유를 진행한다.

  • 최대 2시간을 넘지 않도록 한다.(인당 30분)
  • 일주일동안 개발한 코드에 대한 리뷰
  • 새롭게 알게된 기술에 대한 간단한 소개

DB 설계

• Redis에 좌석 점유를 할 때 어떻게 공유자원 접근으로 인한 비효율성을 해결하지 고려해보아야 한다.

디자인

디자인-피그마

• 초기 페이지 변경
  • 현재는 한페이지에 모든 공연 정보를 보여주는데, 추후에 페이지네이션 도입
  • 프로그램 하나를 클릭하면 해당 페이지로 이동
• 메인 페이지
  • 필터링 기능 혹은 검색 기능이 있으면 좋겠다. → 장르별, 예매 오픈 시간 등등
• 좌석 선택 페이지
  • 처음 들어왔을 때, 섹션을 메인 좌석 선택 그림에서 선택하고, 좌석 화면을 보여줘야하지 않을까?
• 화면 크기를 고려해보았을 때, 추후에 반응형을 넣어야할 것 같다.

섹션별 좌석 렌더링 방식

• 클라이언트가 현재 보고 있는 섹션의 이벤트만 수신할 것인가?
  • 그럼 클라이언트는 섹션을 옮길 때마다 서버에 해당 사실을 알리는 요청을 보내야 한다.
    • SSE로 감당이 될까? 웹 소켓으로의 전환이 필요할 수도 있으며, 이는 요구되는 자원이 너무 커진다.
    • SSE를 유지하고 섹션을 옮길 때 API 요청을 하면? → 혼잡한 상황에서 응답 속도가 늦어지면 UX가 많이 저해된다.

일단은 클라이언트가 별도의 정보 송신 없이 모든 섹션의 이벤트를 수신하도록 한다. → 양질의 UX 유지, 이 경우 모든 섹션 바깥에서 바라볼 때 각 섹션의 좌석 점유 상태를 업데이트 받을 수 있다는 장점도 생긴다.

API명세서 수정

• DB 및 이미지에 맞게끔 API 명세서 수정 완료

• 메인 페이지에 대한 API 명세서 추가 완료

• API명세서

목데이터(API)제공은 어느 기능까지 제공?

• /reservation [GET]
• /booking/re-permission/:event-id [GET] - sse
  • 연결이 되면 100명 정도 남아 있고,
  • 1초마다 10명씩 줄어들도록
  • 0명이 되면, 입장 가능 요청을 보내고 연결을 끊는다.
• /reservation/:event-id [GET] - sse
  • 특정 좌석들에 대해서 랜덤으로 변경
  • 1초마다 랜덤(구현 힘들면 정해진 패턴도 무관)으로 변화된 좌석 현황이 변화된 정보를 보낸다.
• 좌석 배치도에 대해서 1개라도 만들어서 DB에 목 데이터로 넣기

인증 인가 기능 추가기능

• 요청이 들어왔을때 인터셉터를 통해서 SessionID를 조회하고 조회한 SessionID에서userID 추출

백앤드 디렉토리 구조

• 각 도메인별로 관리하기
  • controller, repository, service, dto, entity 각 도메인 디렉토리에서 관리하기
  • controller, repository, service, dto, entity등 디렉토리 만들고 안에 파일을 저장
  • module파일은 하나뿐이니 디렉토리 만들지 않기

백엔드 필요한 도메인

• program
  • 공연정보
• event
• reservation
  • 예매완료 정보
    • CRUD - 예매 확정, 취소, 조회
• seats
• booking
  • 예매 과정
    • 대기큐, 좌석 선점등을 담당