- 야놀자 서비스 중 숙소 검색 및 예약 페이지의 API를 구현해보는 것
- JPA를 통해 DB와 연결하고, 서비스에 맞는 테이블 릴레이션 설정
- Front-end 개발자가 API를 사용하기 쉽게 일정한 형식의 Response(Error 메세지 포함) 리턴
- Back-end API만 구현
- Issue 생성 → Issue 번호를 딴 branch 생성
- 목적에 따라 feat, refact, debug 폴더로 branch 관리
keyword
- feat : 새로운 기능이 추가 됨
- refact : 기능 혹은 성능 개선
- debug : 버그 수정- 개발 완료 후 main branch 내용을 current branch로 Merge한 후 Pull Request
- 직접쿼리 작성 시 결과값에 대한 convert 이슈
- JPQL 쿼리 작성 및 DTO로 결과 반환
- 예약 Entity 양방향 관계로 인한 StackOverFlow 이슈
- Json으로 직렬화할 속성 무시 (@JsonIgnore)
- 직렬화할 대상 결과객체 외 다른객체 제외 (@ToString(exclude =...))
- postsql 예약어 사용으로 인한 Syntax 이슈
- User테이블 명 변경(User → Customer)
- OneToMany 릴레이션으로 DAO 생성했으나 숙소 조회(select)할 때 마다 매번 Join을 해야해서 성능 저하 발생
- 릴레이션 해제하고, Detail한 정보 필요시에만 쿼리를 두번(N+1) 실행하여 조회
- 호텔 측에 남아있는 방의 개수를 초과해서 예약을 할 수 있는 문제
- 체크인/체크아웃 날짜를 기반으로 숙소 검색 및 예약을 할 때 빈 방이 있는지 계산 (숙소 방 개수 정보와 해당 기간의 예약 내역을 비교하여 도출)
- 체크인- 체크아웃 기간을 지나치게 길게 설정하여 빈 방을 검색하는 경우 loop가 길어져 부하를 주는 문제
- 비즈니스 로직에서 제한 설정 (ex: 예약 가능한 기간은 최대 7일, 빈 방 검색 가능한 기간은 오늘로부터 한달 이내)
- 이에 따른 유효성 검증 및 예외처리 추가
- 상대적으로 빈 방 계산 정확도가 덜 중요한 숙소 검색 기능에서는 체크인 날짜만 체크, 정확도가 중요한 예약시에는 체크인 - 체크아웃 기간의 모든 날짜의 빈방 확인
- Front-end에서 API Response를 받아 처리할 때 데이터 형식이 제각각이면 일관성 있는 처리가 어려운 문제
- CommonResponse로 API의 응답 타입 형식화
- 일일이 커스텀 예외 클래스를 만들면 지나치케 클래스가 많아지는 문제
- CustomException과 CommonCode로 에러 메세지 공통 관리