끄적끄적

최근에 필자가 속해있는 회사에서 nestia 를 사용하도록 서버 리펙토링을 완료했다. 참고로 nestia 란 라이브러리는 Nestjs 를 조금 더 쉽게 쓸 수 있도록 해주며 성능적으로도 훨씬 빠르게 만들어 주는 라이브러리로, 한국에 있는 개발자 분이 개발한 멋진 라이브러리다. 이전 포스팅에서 nestia sdk 에 대해서 간단하게는 남겼지만 모노레포 지원이 잘 안되는 이슈로 이는 적용 못했지만 굳이 sdk 를 쓰지 않더라도 가독성 및 생산성 면에서 훨씬 좋아지는 경험을 했기에 이번에 포스팅을 남겨보고자 한다. DTO 를 Interface 로 변경 기존에 class-transformer, class-validator 를 활용했을 때의 코드를 우선 확인해보자. 아래 코드가 왜 나오는지 이해하기 위해서는 n..

이번 포스팅에서는 조금 오래된 개념인 Repository 패턴, 그 중에서 추상화에 대한 이야기를 해보고자 한다. 원래 이전부터 쓸까 했지만 이제는 많은 개발자들이 대부분 이 개념을 인지하고 있다고 생각해서 건너뛰었었다. 하지만 최근에 어떤 개발자와 이야기 할 때 아래와 같은 대화를 나눈적이 있었다. A : Nest에서 TypeOrm 0.2 에서 TypeOrm 0.3 으로 마이그레이션하기 어려워요. 필자 : 아 connection 이 datasource 로 바뀌어서 조금 달라지긴 했더라고요. A : 특히나 TypeOrm 0.2 @EntityRepository 가 삭제되어서 마이그레이션 할 때 고려할 부분이 많아요. 필자 : 혹시 TypeOrm 에서 제공하는 Repository 를 도메인에서 직접 사용해서..

현재 회사의 대부분 서버는 Docker를 기반으로 배포되고 있다. 그런데 이 때 특정한 서버에서 배포 시마다 운영에는 문제 없는 에러 로그가 지속적으로 발생하는 이슈가 있었다. 물론 이 문제로 인해 다른 로직에 오류가 발생한 적은 없었기 때문에, 그 동안 다른 개발 작업에 집중하다가 최근에 조금 여유가 생겨 이 이슈를 조사해보기로 했다. 결론부터 이야기 하자면 문제의 원인은 docker stop 명령 실행 시 docker 는 컨테이너에 TERM signal (SIGTERM) 을 보내고 10 초 동안에도 종료되지 않았다면 Kill signal (SIGKILL) 을 보내 강제로 종료시키는 과정에서 발생했다. 컨테이너는 SIGTERM 시에 모든 리소스를 정리하고 종료되어야 하지만, DB 리소스는 정리되었으나 ..

한국에서 nestjs 로 개발하는 개발자라면 typia 에 대해서 한번쯤은 들어봤을 것 같다. 이 라이브러리에서 문제로 지적하는 부분이 nestjs 공식문서 예시로 제시하는 class-validator 가 성능적으로 문제가 크다는 것이다. 때문에 이러한 느린 라이브러리의 문제로 "typescript(javascript) 가 느리다" 라는 잘못된 인식까지 퍼질 수 있다고도 한다. 특히나 대부분의 nestjs 개발자라면 class-transformer + class-validator 기반으로 request 검증을 할테고, 객체 transform 액션에도 class-transformer 를 적극적으로 활용하고 있을 것이라 느리다는 인식이 더 커질 수 있을 것 같다. 여기서 성능이 느려지는 가장 큰 이유중 하나..