체인의정석

Controller 부분에서 아래와 같이 함수를 짜면 잘 보이지만 swagger에서는 잘 잡히지 않는다. @Param('ethAddress') ethAddress: string, @Query('쿼리파라미터1') 쿼리파라미터1?: string, @Query('쿼리파라미터2') 쿼리파라미터2?: string, @Query('쿼리파라미터3') 쿼리파라미터3?: number, 다음과 같이 optional 하게 주려고 해도 required로 나온다. https://github.com/nestjs/nest/issues/2169 Please Add `optional: boolean` to @Query route param decorator · Issue #2169 · nestjs/nest I'm submitting ..

이더리움 value의 경우 숫자가 커서 빅넘버처리를 안해주면 에러가 나게 된다. 단위가 너무 크기 때문인데 조사해본 결과 빅넘버 처리는 결과 목적에 맞는 모듈을 사용하는것이 정답이라고 한다. 타입스크립트도 사용하였으니 한번 유명한 ether.js를 찾아보았다. 처음 써보는데 너무 편리했다. 일단 ether.js 에서 사용하는 bignumber의 경우에는 elliptic로직에서 쓰이는것과 같은 방법이기 때문에 가장 안전하다고 한다. 오랜기간 서칭을 한 결과 몇가지 케이스에 대한 방안을 알 수 있었다. 1. 이더리움 단위로 만들 경우 //ethers.utils.formatEther( value ) ⇒ string const value = BigNumber.from("1000000000000000000"); ..

입력값을 수정하는 부분이 nest.js에서 매우 중요한데, 사실 이게 타입스크립트를 쓰는 이유이기도 한다. 타입스크립트를 사용하게 되면, 타입을 모두 지정해 줄 수 있어서 모든 request , response 그리고 그 안에 들어가는 요소들을 객체화 시키고 타입을 지정하여 모든 상황에 대한 예외를 잘 잡아 줄 수 있다. 1. Class validator 사용의 경우 이번 프로젝트를 구현하면서 가장 많이 사용한 것은 class-validator 이다. Validation Pipe 모듈의 경우 클래스 형태로 요청을 받아줄 때 사용가능하기 때문에 일반적인 string의 형태나 단일 타입에 적용 시킬 수는 없다. 따라서 조회를 쿼리 파라미터로 실행하는 경우 class-validator를 실행한다고 보면 된다...

1. 공통 예외처리 부분 에러 처리의 경우 결과적으로 invalid input과 internal server error로 나뉘었다. 여기에 대한 구조는 다음과 같다. @Get('/:ethAddress/경로') async 함수이름( @Param('ethAddress') ethAddress: string, . . . @Query('page') page?: number, ): Promise { //오류의 경우 공통 부분으로 빼두어서 관리 const 객체화된요청 = new RelatedTransactionsRequest( ethAddress, new Date(fromDate), . . page * 1, ); const errors = await validate(객체화된요청); //쿼리 파라미터가 있는 경우 va..

Nest.js에서 여태까지 class validator를 사용하기 위하여 constructor를 사용하여 모든 클래스를 생성한 하여 valditaion을 진행하였다. 하지만 validation Pipe를 사용하면 이러한 과정을 모듈로 깔끔하게 할 수 있다는 사실을 알게 되어서 적용해 보려고 한다. 이걸 잘 사용하면 중복된 코드를 대량으로 줄일 수 있을것 같다. 우선 constructor 부분이 삭제가 되면서 1차적으로 코드가 깔끔해지며, 2차적으로 공통 모듈로서 validation하는 부분을 설정해 줌으로서 더 클린하고 유지보수가 쉬운 코드가 나오게 될 것으로 기대하고 리팩토링을 진행하도록 하겠다. 먼저, validation Pipe의 경우 nest.js 공식 document에 있기 때문에 이를 정독해보..

현재 진행중인 프로젝트는 장기 프로젝트로 url을 작성할 때 확장성이 있게 만들어야 한다. 아래와 같이 원래의 경로에 중간에 쿼리 파라미터가 들어가게 될 경우 시스템이 인식하기로는 파라미터에 ethAddress가 들어가던지 btcAddress가 들어가던지 같은 값으로 인지하게 된다. 따라서 아래의 코드와 같이 확장성을 고려한 경로를 만드려면 쿼리 파라미터의 변수 이름을 바꾸는 것은 아무런 의미가 없고 경로를 하나씩 더 추가하여 만들어야 한다. 장기 프로젝트의 경우 맨 처음부터 확장성을 고려하여 아래와 같이 예상되는 기능별로 경로를 최대한 구조 수정 없이 변경이 가능하도록 사전작업을 해두는것이 유리한다고 본다. /addresses/${ethAddress}/... //원래의 경로 /addresses/eth/..

회사의 로거 모듈을 설치하는데 1.default) is not a function 가 들어간 에러가 나왔다. 이러한 에러는 구글에 해결책이 있었는데 https://stackoverflow.com/questions/61524130/typescript-babel-import-causing-1-default-is-not-a-function Typescript/babel import causing "_1.default is not a function" I am trying to use https://github.com/timmywil/panzoom from a typescript project compiled with webpack and babel. The problem is that the typescrip..

아래와 같이 페이지네이션에 대한 기본값을 설정하는 부분을 3항 연산자로 더 간단하게 바꾸어 보았다. export const paginationSet = (request) => { if (!request.rpp) { request.rpp = 20; //TODO 3항 연산자로 1줄로 변환 } if (request.page == 0 || request.page == 1) { request.page = 0; } else { request.page -= 1; } return request; }; 위와 같은 코드가 아래와 같이 보여지게 된다. export const paginationSet = (request) => { request.rpp ? (request.rpp = 20) : (request.rpp = 0);..