끄적끄적

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

작년 초에 선착순 NFT 판매 이벤트를 개발해야 한 적이 있었다. 당시 선착순 이벤트의 경우 Redis 에서 분산락 알고리즘으로 제공하는 redlock 을 활용해서 개발하는 경우가 대부분이였으며 정보도 많았었다. 당연히 필자 또한 빠르게 개발하기 위해 이를 활용했었다. 그러나 이벤트가 종료된 후에는 선착순 판매가 아닌 단순히 상품(NFT)을 열어두고 판매하는 상황이 대부분이게 되었다. (사실 이벤트 때도 많은 인원수가 몰리지 않아 실망했던 기억이 있다.) 시간이 흐르면서 레디스 자체가 성능적으로 큰 필요가 없는 경우가 대부분이라는 사실을 알게 되어 쓸데 없는 비용을 줄이기 위한 작업을 진행하기로 했다. 요구사항 자체는 간단했다. 기존 비즈니스 로직은 건드리지 않을 것 언제든 선착순 이벤트로 바뀔 시 빠..

테스트를 하다보면 예외사항을 테스트해야 하는 경우가 자주 생긴다. 이 때 필자의 경우 어떻게 예외 테스트를 하고 있는지에 대해 이야기를 해보고자 한다. 이 포스팅에서는 커스텀한 에러를 던지고 있으며 그 형태는 아래와 같다고 가정하자. export class CustomError extends Error { name: string; message: string; code: string; stack?: string; constructor(code: string, message: string, name?: string, stack?: string) { super(message); this.name = name || code; this.message = message; this.code = code; if (..

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

백엔드를 개발하다보면 가장 흔하게 처리해야 하는 부분중 하나가 페이지네이션 부분이다. 그 중에서도 요즘에는 커서 기반의 페이지네이션 처리를 많이 수행하며 단순히 sequence 로만 처리하는 것이 아니라 여러 조건하에서 정렬할 필요가 있다. 그 때 커서 페이지네이션 처리를 하다보면 중복된 커서 데이터에 의해 특정 레코드를 건너띄는 경우가 자주 발생하며 이를 처리할 필요가 있다. 이번 포스팅에서는 이런 문제에 대한 예시와 해결방법들에 대해서 정리해볼 생각이다. 들어가기 전에 들어가기 전에 테스트를 할 테이블을 정의했다. 상품이라는 테이블이 있으며 seq 를 PK 로 가지고 있으며 price 와 created_at 을 인덱스로 가지면서 이를 활용해 상품을 최신순 혹은 가격순으로 정렬하고자 한다. 또한 테..

Nestjs 를 개발하다보면 custom parameter decorator 를 개발할 필요가 있다. 물론 공식 문서 예제로 주어지는 @User 와 같은 형태가 존재하고 이를 자주 사용하곤 하지만 Nest 문서에서 주어진 것만 가지고 개발하기에는 한계점이 존재한다. 그래서 이번 포스팅에서는 nestjs 에서 기본적으로 제공하는 함수를 활용하는 것이 아닌 메타데이터를 직접 사용해서 custom parameter decorator 를 만드는 작업을 진행해보도록 한다. Documentation | NestJS - A progressive Node.js framework Nest is a framework for building efficient, scalable Node.js server-side applic..

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

최근에 타입스크립트 타입 챌린지 라는 것을 알게 되어 하루에 한두문제씩 계속 공부중이다. 하지만 실상 개발할 때는 어떻게 활용해야 할까 고민도 많고 익숙하지 않아서 쓰는데 어려움이 많았다. 그래서 어디 적용해보면서 공부를 해볼까 고민하던 중 이전에 블록체인 private key 를 추출하는 개발을 했었는데, 이 때 BIP44 Path 를 이상하게 입력하는 바람에 오랜 시간 삽질했던 경험이 떠올랐다. 그래서 이를 직접적인 타입으로 잡아볼까 해서 한번 만들어 보았다. 참고로 BIP44 에서 path 는 아래와 같은 형식을 정의하고 있다. # purpose 는 BIP44 에서는 44 로 고정한다. m / purpose' / coin_type' / account' / change / address_index 이..

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

이전 포스팅에서 이더리움 dApp 개발을 위해 Truffle 과 Ganache 를 세팅해 보았었다. 물론 Truffle 의 경우 현재도 많은 회사에서 사용중이지만 최근 트랜드에서는 블록체인 개발자 대다수가 개발 환경으로 Hardhat 을 사용한다. 둘 다 npm 을 활용해서 설치하는데 기간을 길게 보아도 Hardhat 사용자 수가 Truffle 을 넘어선지는 꽤 오래되었다. 또한 필자의 회사에서도 현재는 Truffle 보다는 Hardhat 을 주로 사용하고 있다. 공식 문서를 확인해보면 Hardhat 을 아래와 같이 설명하고 있다. smart contract 와 dApp을 편집, 컴파일, 디버그, 배포하는 데 필요한 다양한 요소로 구성되어 있는 이더리움 소프트웨어 개발 환경이다. 결국에는 trffule..