일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 자청
- validator
- typescript
- AWS
- 일상속귀한배움
- googleapis
- 역행자
- Nestjs
- PRISMA
- 조영호
- 오브젝트
- 객체지향의사실과오해
- UNiQUE
- OOP
- 클린코드
- 개발자
- nodemailer
- futureself
- nodejs
- Object
- 스터디
- serverless
- 세이노의가르침
- 북스터디
- 독후감
- BOOK
- 부자아빠가난한아빠2
- 퓨처셀프
- Study
- Validation
- Today
- Total
목록validator (2)
우당탕탕 우리네 개발생활
결론부터 말하자면 validator와 transformer의 데코레이터들은 다음과 같은 순서로 동작이 됩니다.Type(class-transformer) -> ValidateIf -> IsOptional -> 기타 class-validator 데코레이터들참고로 ChatGPT는 IsOptional과 ValidateIf를 반대로 설명해 줬었고 이로 인해 더 혼란스러웠지만 머릿속엔 강하게 각인될 시행착오가 됐습니다 :)개요validation은 항상 중요합니다다. 제 블로그에서도 관심 있어해 주시는 keyword가 validation과 관련되어 있습니다. 아래 포스트를 그나마 많이 봐주셨답니다.https://khjeong0423.tistory.com/31 [Nestjs] ! 과 ? 그리고 class-validat..
백엔드 서버를 구성하면서 중요하게 생각하고 있는 것 중 하나는 정교한 validation입니다. 보통 저는 서버를 구축한 이후 API 문서를 작성합니다. 각 API 마다 Request에 필요한 파라미터들의 타입명시를 잘해놓고 테스트도 곧잘 합니다.(API문서에 명시한 스펙으로 말이죠.) 하지만 온갖 다양한 타입의 파라미터들을 Request에 담아 테스트를 하다 보면 예기치 않은 에러들을 마주하는 상황이 종종 생깁니다. 예기치 않은 에러라는 것은 문서에 명시하지 않은 에러코드를 나타낸다는 뜻이고 이는 해당 API를 사용하는 클라이언트 입장에서 핸들링할 수 없게 됩니다. 이로 인해 생길 수 있는 피해가 적다고 해도 이는 치명적인 상황으로 여기는 게 맞다고 생각합니다. 이런 생각으로 저는 validation적..