일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 스마트 컨트렉트 함수이름 중복
- chainlink 설명
- ethers type
- 러스트기초
- git rebase
- 계정추상화
- Vue
- 스마트컨트렉트 예약어 함수이름 중복
- 오블완
- erc4337 contract
- 러스트 기초
- 컨트렉트 배포 자동화
- 러스트 기초 학습
- 티스토리챌린지
- SBT표준
- Vue.js
- ethers typescript
- 머신러닝기초
- ethers websocket
- rust 기초
- 컨트렉트 동일한 함수이름 호출
- vue기초
- 스마트컨트렉트테스트
- multicall
- ambiguous function description
- erc4337
- 체인의정석
- 스마트컨트렉트 함수이름 중복 호출
- ethers
- ethers v6
- Today
- Total
목록분류 전체보기 (496)
체인의정석
검색할때 결과값으로 오는 데이터의 양이 많을 시에는 페이징 처리를 통해서 나누어서 불러 올 수 있다. 페이징 처리는 쿼리문에서 select * from Chain LIMIT 10 OFFSET 1 이런식으로 마지막에 limit에는 한번에 가져올 데이터의 양 offset은 어디서부터 가져오지? 하는 기준점을 잡아주게 된다. 이때 limit에 들어오는 값과 OFFSET에 들어오는 값을 넣어주어야 한다. limit에 들어오는 값은 보통 요청 파라미터에서 rpp로 두고 OFFSET 부분은 page로 둔다. 따라서 설계서에서도 request 부분에 모두 rpp와 page를 두기로 하였다. 또한 만약 페이징 처리가 없는 부분이 있다면 이 부분은 0으로 하여 페이징 처리가 있는 경우의 쿼리문과 페이징 처리가 없는 부분..
이번에는 controller 부분과 dto 부분을 수정하여 구조를 더 체계적으로 만들었다. 주위 선임개발자 분들의 코드를 보고 질문을 하여 받은 피드백을 바탕으로 코드를 체계화 시켜 보았다. 수정전 코드 다음과 같이 이더리움 주소값을 계산하는 조건식을 넣었다. 하지만 이러한 값은 @Param에 객체 클래스를 만들어서 class-validator에 적용시키는것이 더 일반적이다. 참고로 이더리움 주소값은 1. 0x 포함 길이 42 2. 들어오는값은 16진수 이 2가지 조건이고 web3에서의 주소값 검사는 체크썸 검사가 나온 결과갑이라고 볼 수 있다. async findOne( @Param('address') address: string, ): Promise { if (address.substr(0, 2) !..
nest.js에서 type ORM을 사용할 때 복잡한 구문은 query builder를 사용하여 구현할 수 있다. https://typeorm.io/#/select-query-builder/what-is-querybuilder TypeORM - Amazing ORM for TypeScript and JavaScript (ES7, ES6, ES5). Supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, typeorm.io 이번에는 query builder를 사용하여 조금 더 복잡한 조건절을 구현하는 것을 해보도록 하겠다. const firstUser = await connection .getRepository(User) .createQueryBuilde..
상황 이더리움 주소값이 틀린 경우 반환하는 에러 상황, 이러한 경우 따로 값을 반환하여야 하나, class - validtaor를 사용하면 기능이 다 작동하고 마지막에 조건을 검사하는 문제가 생김. 그 결과 성능이 떨어지기 때문에 입력값을 받자마자 검사를 해주고 마지막에 class-validtor를 써서 한번 더 검사해주는것이 맞다. 이 경우 web3를 사용할 수 있다. 하지만 web3를 사용할 경우, 풀노드와 연결을 한번 해야 한다. 풀노드와 연결을 하는 부분은 현재 모듈에 없는데 이것때메 만들기가 좀 그렇다. 성능이 역시 떨어질것 같다. 따라서 db에 있는 16진수 + 42개의 길이를 통하여서 검사를 하였다. if (address.substr(0, 2) !== '0x' || address.length..
API 설계를 하였는데 내가 설계한 부분은 그냥 data 만 들어간 부분이였다. 따라서 API의 응답도 구체화 시켜서 더 상세하게 설계하기로 하였다. 구현에서 다시 설계로 돌아와서 살펴보겠다. 조회할때도 상황에 따라서 GET과 POST를 구분한다. 상황에 따라서 get에 대한 경우와 post에 대한 경우를 구분한다. get에 대한 부분은 파라미터가 하나일 때 사용하면 괜찮다. POST인 경우 여러개의 입력값을 받아서 복잡한 쿼리를 실행 할 때 POST를 사용한다. 설계시에 이를 고려하여 설뎨를 해야 한다. 결과 값에 대한 객체를 만들어 주어야 한다. 결과 값에 대한 객체를 만들어주기 위하여 전송하는 데이터는 data로 두고 그 외에도 code 와 message를 리턴해 준다. 각 예외 상황에 맞게 알맞은..
https://github.com/typestack/class-validator GitHub - typestack/class-validator: Decorator-based property validation for classes. Decorator-based property validation for classes. Contribute to typestack/class-validator development by creating an account on GitHub. github.com class-validator에서 이더리움 주소도 판별해 준다. 타입스크립트 타입 지정할 때 이걸 이용해서 짜주어야겠다.
오랜 방황 끝에 결국 다음과 같이 구조를 짤 수 있었다. ├── addresses │ ├── addresses.module.ts │ ├── controller │ │ ├── addresses.controller.spec.ts │ │ └── addresses.controller.ts │ ├── dto │ │ ├── get-contract-command.dto.ts │ │ └── get-contract-response.dto.ts │ ├── entities │ │ └── addresses.entity.ts │ └── service │ ├── addresses.service.spec.ts │ └── addresses.service.ts ├── app.module.ts ├── config │ └── config..
다음을 통해 시스템 환경변수를 설정하였다. https://docs.nestjs.kr/techniques/configuration 네스트JS 한국어 매뉴얼 사이트 네스트JS 한국, 네스트JS Korea 한국어 매뉴얼 docs.nestjs.kr env 파일로 불러오는 부분은 계속 에러가 나서 나중에 마무리 하기로 하고, 일단 하드코딩으로 넣은 후 swagger를 먼저 보았다. https://docs.nestjs.kr/openapi/introduction 네스트JS 한국어 매뉴얼 사이트 네스트JS 한국, 네스트JS Korea 한국어 매뉴얼 docs.nestjs.kr import { NestFactory } from '@nestjs/core'; import { AppModule } from './app.modu..