search

review-with-ai / backend

0 stars 0 forks source link

개발 서버 배포 준비 및 예외 처리 정책 수정 #2

Closed i960107 closed 2 months ago

i960107 commented 3 months ago

🔍 해결하고자 하는 이슈

  1. 개발 서버 구성
  2. 개발 API 서버에 배포 필요할 수 있도록 Swagger, Sentry 등 연동 필요
  3. 예외 발생시 응답 메시지로 원인 표현할 수 있도록 예외 처리 정책 필요

💡 주요 변경사항

1. 개발 서버 구성

[참고] nCloud 사용 이유 : f-lab에서 제공하는 크레딧으로 무료 사용 가능.

  1. API 서버 - nCloud 서버 사용. 도메인 연결 서버 사양: [Compact] 2vCPU, 2GB Mem [g1] ubuntu-18.04 도메인 연결: dev.api.ai-review.site

  2. DB 서버 - nCloud Cloud DB for MySQL 사용 서버 사양: Standard] 2vCPU, 4GB Mem

  3. Redis - 비용 이슈로 API 서버에서 같이 실행.

    2. Swagger, Swagger 연동

  4. Swagger로 API 명세 작성

API 명세 보기

  • API 명세는 최대한 스키마와 예시를 함께 제공한다.

  • 200 상태 뿐만 아니라 실패시의 4XX 응답 정보도 제공한다.

  • 응답 코드에 따라서 다른 응답 메시지 예시를 제공한다.

    image

  • @APIExceptionExample 어노테이션을 생성해서 가능한 예외를 별도의 문서로 표시, 스웨거를 위한 코드가 소스코드 침투하는 것을 최소화한다.

  • 핸들러 메소드별로 config/swagger/docs 의 각 클래스에 대응되며, docs의 각 클래스는 각 핸들러에서 발생 가능한 예외를 기술한다.

  • @ExplainError로 예외 상황을 설명할 수 있고, 이는 스웨거 응답 예시에 표시된다.

  • 예시 : AccountController.join() 는 config/swagger/docs/UserJoinPossibleExceptions 에 대응된다.

    스크린샷 2024-05-28 오후 1 47 57 스크린샷 2024-05-28 오후 1 40 37
  1. Sentry 연동
  • 센트리 환경 loca, dev로 분리
  • logback 추가 : 로그는 콘솔 및 센트리 출력. 콘솔은 INFO 레벨부터 출력.
  • 처리되지 않은 예외 발생 시나, WARN 레벨 이상의 로그 발생시 센트리 이슈 생성됨

3. 예외 처리 정책

  • API서버에 docker-compose.yml, .env 파일 만들어둠
  • docker로 redis, jar 이미지 실행
    1. 사용자 이름, 패스워드, 닉네임 검증 어노테이션 추가
  • 매번 NotBlank, Length, Pattern으로 검증하는 것은 비효율적이고 공통 정책으로 관리하기가 힘듬
  • 각 어노테이션 별 Validator 추가
  • 비밀번호의 경우 validation group을 사용해서 일반 유저에게는 적용되고, oauth 가입 유저(패스워드 없음)에게는 적용되지 않도록 설정
  1. validation 에러 메시지는 errors.properties로 공통 관리. 타입 별로(NotNull, NotBlank 및 추가한 검증 어노테이션 ex UserName) 메시지 추가. 범용적으로 적용되도록 함.
  2. 패키지 구조 수정
    • 도메인 모듈의 domains 패키지 내부에 각 도메인 별로 패키지 생성해 엔티티, 레포지토리, 도메인 예외를 관리한다.
    • 도메인 모듈의 common/exception에서 예외 인터페이스 및 추상 예외 클래스를 관리한다.

✅ 리뷰가 필요한 사항

green-ribbon-admin commented 3 months ago

Entry 검증 방법 : Entry에 검증 어노테이션 추가해도 적용되지 않고 DB에 삽입 시 ConstraintViolationException 발생. 제약 조건에 만족하지 않는다면 서비스 레이어 계층에서 실패시키기 위해 수동으로 검증하는데 적절한 방법인가요 ??

=> 음 예시로 고민 되는 포인트 한번 알려주시면 좀더 명확하게 도움드릴수 있을거같아요 음 이건 사실 컨트롤러에서 받는거에서 1차로 밸리데이션 하고 서비스레이어서 최종 저장될때 DataIntegrityViolationException 이 터트려서 체크하는게 낫거나 필수는 null이면 안되는거나 하는거는 서비스레이어에서 제어가 나을거같아요

mr 메시지 너무 자세하거나 중요한 포인트를 놓치고 있을까요? mr 메시지 단위가 너무 큰가요?? 😭 ㅠㅠ 조금 많아서 브랜치 전략 알려줄게용

green-ribbon-admin commented 3 months ago

앗 그리고 배포 관련해서 설명좀 드릴려고 하는데 혹시 배포 환경 셋팅 코드가 없느거 같네요 ㅜ