[Re-Open] Sentry 연동, 코드베이스에 Exception Filter, Response Interceptor 적용

[J-Hoplin]

Parent Branch 삭제로 close되어서 다시 PR 올립니다 ㅜㅜ...

PR 개요

• Sentry 연동
• [제안] 코드베이스에 Exception Filter, Response Interceptor 추가

PR 중점사항

해당 PR에서 적용해본 아래 사항들에 대해 같이 논의 및 개선해보고 싶습니다! 해당 PR에서는 코드를 적용하기 위함보다는 제안을 드려보고자 PR을 요청드리게 되었습니다.

• Exception Filter제안 및 논의를 해보고싶습니다.
• Response Interceptor제안 및 논의를 해보고싶습니다.
• Custom Exception제안 및 논의를 해보고싶습니다.

Custom Error 선언방법

Custom Error는 createException을 호출해 반환되는 익명클래스를 상속받는 형식으로 선언합니다. createException의 Parameter 정보는 아래와 같습니다.

• statusCode
  • Type: number
  • Required: true
  • Description: Http 상태코드입니다.
• errorMessage
  • Type: string
  • Required: true
  • Description: Error Payload에 들어갈 메세지입니다.
• errorCode
  • Type: string (Enum을 통해 선언하는것을 권장드립니다)
  • Required: false, 기본값은 Unknown으로 들어갑니다.
  • Description: 커스텀 에러코드입니다.

enum GlobalExceptionCode {
  AuthenticationFailedException = 'P1001',
}

export class AuthenticationFailedException extends createException(
  401,
  'Fail to authenticate',
  GlobalExceptionCode.AuthenticationFailedException,
) {}

Payload 정보

Exception Filter와 Response Interceptor에 의해 동일한 값을 반환합니다. ICommonResponse interface를 따르며, 아래와 같이 정의되어있습니다.

// common/types/types.d.ts
export type ExceptionPayload = {
  code?: string;
  message: string | object;
};

export interface ICommonResponse {
  success: boolean;
  data: any;
  error: ExceptionPayload;
}

• success: 응답 성공여부
• data: 응답이 success인 경우, 응답 데이터를 반환됩니다. 응답이 fail인 경우에는 null로 반환합니다
• error: 응답이 fail인 경우, 에러 정보를 반환합니다. 응답이 success인 경우에는 null로 반환합니다

응답이 성공인 경우

응답이 실패인 경우 - Custom Error

응답이 실패인 경우 - JavaScript Error, Nest.js 내장 예외 객체

추가적으로 커스텀 에러를 통해 예외 반환시 Sentry에서 커스텀 에러코드별로 추적할 수 있도록 적용하였습니다.

[hye-on]

고생했어!!👍

[Marades]

200번대면 성공, 400, 500번대면 실패라는 싱크를 프론트와 맞춘다면 success필드를 없애고 depth를 하나 없앨 수 있겠다는 생각이 드는데 준호 생각은 어때?!
success필드나 response형태에 대해서 프론트 애들이랑 해커톤 시작 때 얘기해봐도 좋겠다는 생각이 드네!

[Marades]

우리 서버팀 다른 애들 생각도 궁금하다
요새 response 관련해서는 전부터 의견이 분분한 영역인 거 같아서!
@J-Hoplin @hye-on @JonghunAn

[J-Hoplin]

Status Code로 실패 여부 확인하는것도 괜찮을꺼같아! success 프로퍼티를 추가한 이유는 Payload에서 succes랑 에러코드로 바로 구분하게 한다면 클라이언트에서 body만 가져와서 바로 판별 할 수 있으니까 더 편하지 않을까라는 생각으로 success 필드를 추가했었어!
형 그러면 response payload도 동일하게 data, error 필드 구분 없이 한 depth로 만 payload 전송하는거를 말하는거야?? 약간 에러케이스랑 성공케이스에서 동일하게 응답 payload형태를 맞출려고 ICommonResponse 타입으로 반환하는거로 작성했는데, 기본적으로 한 depth가 생기는 것에 대해 클라이언트 분들 의견을 아직 못 물어봤었어. 형이 말한 것처럼 같이 이야기 해서 맞춰보는 과정이 필요할것같아!