끄적끄적

최근에 필자가 속해있는 회사에서 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 를 도메인에서 직접 사용해서..

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..

최근에 타입스크립트 타입 챌린지 라는 것을 알게 되어 하루에 한두문제씩 계속 공부중이다. 하지만 실상 개발할 때는 어떻게 활용해야 할까 고민도 많고 익숙하지 않아서 쓰는데 어려움이 많았다. 그래서 어디 적용해보면서 공부를 해볼까 고민하던 중 이전에 블록체인 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 를 적극적으로 활용하고 있을 것이라 느리다는 인식이 더 커질 수 있을 것 같다. 여기서 성능이 느려지는 가장 큰 이유중 하나..

요즘 ChatGPT 에 대해서 시끌벅적하다. 특히나 최근에 Micorsoft 에서 copilot 을 단순한 개발이 아닌 ms office 에 적용하기도 하면서 업무에 직접적으로 영향을 주기 시작하고 있고 ChatGPT Api 대신 ChatGPT 플러그인이 나오면서 일반인도 충분히 사용 가능하도록 출시되었다. 즉, 이제는 실생활에 밀접하게 적용되고 있다고 생각해 볼 수 있다. 이렇게 AI 와 대화하고 여러 의견 및 정답을 얻어가는 과정을 프롬프트 엔지니어링이라고 하는데 개인적인 생각에 앞으로 프롬프트 엔지니어링이라는 말은 사라지고 업무를 할 때 자연스럽게 써야하는 미래가 올 것 같다. 비유해보자면 과거에 펜과 종이를 통해 업무를 보다가 지금에 와서는 워드 및 한글 등을 통해 모든 업무를 컴퓨터화해서 보고 ..

백엔드에서 다른 팀에게 API 문서를 전달하는 방법에는 여러가지가 있다. Swagger 를 사용해서 문서를 전달할 수도 있고 Postman 을 이용해서 API 문서화를 시킬 수도 있다. 자바(스프링) 진영에서는 Rest Docs 와 같이 테스트 코드를 강제화 해서 문서를 만들어내는 방식이 유행하는 것 같다. 하지만 어떻게 문서를 넘기던지간에 프런트 입장에서는 백엔드가 만들어진 문서를 보고 API DTO 들을 다시 만들어 내는 과정이 필수적이며 여간 귀찮은 작업이 아니다. 그런데 우리 회사는 백엔드는 node.js(Nest.js), 프런트는 react-native & react 로 모든 개발 언어를 Typescript 로 맞춰서 개발중에 있다. 그래서 작년 초에 프런트 개발자가 이런 요구를 해왔다. 어차피..