우당탕탕 우리네 개발생활

결론부터 말하자면 validator와 transformer의 데코레이터들은 다음과 같은 순서로 동작이 됩니다.Type(class-transformer) -> ValidateIf -> IsOptional -> 기타 class-validator 데코레이터들참고로 ChatGPT는 IsOptional과 ValidateIf를 반대로 설명해 줬었고 이로 인해 더 혼란스러웠지만 머릿속엔 강하게 각인될 시행착오가 됐습니다 :)개요validation은 항상 중요합니다다. 제 블로그에서도 관심 있어해 주시는 keyword가 validation과 관련되어 있습니다. 아래 포스트를 그나마 많이 봐주셨답니다.https://khjeong0423.tistory.com/31 [Nestjs] ! 과 ? 그리고 class-validat..

레거시 코드를 다루며 모듈의 Circular Dependency와 관련된 다소 희귀한(?) 케이스의 문제를 경험했다. 바로 barrel files와 관련된 이슈이다.Circular Dependency와 관련된 내용은 공식문서를 통해서 이전에 공부했던 적이 있는데 그때는 유심히 보지 않았던 부분이 바로 위 문제의 원인이었다. 관련된 내용은 공식문서에 기재되어 있다.Barrelbarrel이 뭔데? 해당 사이트에서는 다음과 같이 barrel의 정의에 대해 알려주고 있다.배럴은 여러 모듈의 내보내기를 하나의 편리한 모듈로 롤업하는 방법입니다. 배럴 자체는 다른 모듈의 선택된 내보내기를 다시 내보내는 모듈 파일입니다.A barrel is a way to rollup exports from several modul..

필요한 기능은 단순히 알맞은 데이터를 엑셀에 매핑한 후 해당 엑셀파일을 이메일로 전송하는 것이었습니다.파일을 물리적으로 저장할 필요가 없었기에 메모리상에서만 파일 객체를 만들고 이를 이메일에 담아 전송할 수 있는 로직을 구현해야 했습니다. nestjs 또는 nodejs 환경에서 이러한 직접적인 레퍼런스를 발견하지 못하였고 여러 가지 힌트를 얻어 직접 구현을 해봤습니다.힌트는 다음과 같았습니다.1. xlsx 라이브러리를 통해 만들어지는 xlsx객체는 다양한 형태(file, string, buffer, base64string 등..)의 객체로 변환이 가능2. MIME타입의 이메일 바디를 raw하게 작성할 때 파일은 base64string으로 보통 변환하여 포함3. nodemailer의 attachment필드..

nestjs 프로젝트에 급하게 이메일 전송기능을 구현할 일이 생겼습니다. 이 기능에는 전송할 이메일에 파일을 첨부할 수 있는 필수 요청사항이 있었습니다.이미 기존 프로젝트 코드 중 AWS SES를 사용할 수 있도록 aws-sdk 라이브러리를 이용하여 유틸성 이메일 서비스를 구현해 놓은 것을 확인했었기에 해당 코드의 재사용을 계획했습니다. 하지만 이미 구현되어 있는 유틸성 이메일 서비스는 파일 첨부를 전혀 염두에 두지 않은 채로 개발되어 있었습니다. 일부 옵션들을 추가하며 파일 첨부를 구현할 수 있을까 가능성을 살펴봤지만 불가능했습니다.  aws-sdk를 사용하면서 이메일에 파일 첨부를 하는 방법은 있었습니다. Multipurpose Internet Mail Extensions (MIME) type ema..

https://youtu.be/3aokY48UZkk?si=YvMfgraC6XaVLKVj 출근하면서 위 영상이 눈에 들어왔다. 요즘 들어 나 자신이 어떤 개발자가 되고 싶은지에 대한 사색에 잠길 때가 많았는데 이에 도움이 될 것 같았다. 말씀을 나눠주신 '네이버 팀장님'으로 지칭되시는 분은 5년 동안 네이버에서 근무하시면서 약 1년 반정도는 팀을 대표하는 팀매니저 역할을 수행하셨다고 한다. 그동안 수많은 면접을 보면서 정립한 주관적인 여러 기준(good, normal, bad)을 시원하게 공유해 주셨다. 좋은 말씀을 많이 나눠주셨는데 그중에서도 한 부분이 와닿았다. 세계에서 가장 유명한 축구선수는 메시와 호날두이다. 하지만 메시 11명으로 구성된 축구팀은 매력적이지 않을지도 모른다. 축구팀에는 공격수, 수..

최근 운영하고 있는 서비스에서 이슈를 발견했습니다.@Injectable()class TestProvider { constructor() {} @Cron('0 */10 * * * *') async methodA(): Promise { // group에 대한 데이터 처리 // 하위 item에 대한 데이터 처리 // 3rd party API } @Cron('0 */10 * * * *') async methodB(): Promise { // 하위 time에 대한 데이터 처리 // 3rd party API }}이슈가 있는 서비스로직에서는 특정 기능과 관련된 서드파티 API를 호출해야 합니다.이 서드파티 API를..

저는 Nestjs + typescript 기술 조합으로 백엔드 개발을 하고 있습니다. 최근 개발을 하면서 두 가지 궁금증이 생겼습니다.- class-validator를 사용하여 decorating한 클래스는 어느 상황에서든 validation을 하는가?- 클래스 멤버 뒤에 붙는 ! 과 ? 는 어떤 역할을 하는가? 위 궁금증들을 해결하면서 정리한 생각을 기록할 겸 공유하려고 합니다.class-validator를 사용하여 decorating한 클래스는 어느 상황에서든 validation을 하는가?제가 있는 백엔드 팀은 서비스코드의 리턴 값과 타입이 일치하는 mapper 클래스 파일을 만들고 이 mappper 인스턴스에 값을 담은 후 리턴을 하는 규칙이 있습니다.mapper클래스 내부에는 class-valid..

백엔드 서버를 구성하면서 중요하게 생각하고 있는 것 중 하나는 정교한 validation입니다. 보통 저는 서버를 구축한 이후 API 문서를 작성합니다. 각 API 마다 Request에 필요한 파라미터들의 타입명시를 잘해놓고 테스트도 곧잘 합니다.(API문서에 명시한 스펙으로 말이죠.) 하지만 온갖 다양한 타입의 파라미터들을 Request에 담아 테스트를 하다 보면 예기치 않은 에러들을 마주하는 상황이 종종 생깁니다. 예기치 않은 에러라는 것은 문서에 명시하지 않은 에러코드를 나타낸다는 뜻이고 이는 해당 API를 사용하는 클라이언트 입장에서 핸들링할 수 없게 됩니다. 이로 인해 생길 수 있는 피해가 적다고 해도 이는 치명적인 상황으로 여기는 게 맞다고 생각합니다. 이런 생각으로 저는 validation적..