Nest Study 1일차
in Legacy on Nest
자바스크립트에서 보통 객체르 생성하면 거의 힙에 들어감
스택에는 호출스택의 실행컨텍스트 들이 저장되고 그외의것들은 거의 힙에저장
Morgan의 로그들을 따로 디비에 저장하는건지 ?
- 이걸 따로 꺼내서 뭐 서비스를 만들거면 그렇게 쓰는게 그게아니라면 센트리나, 데이터독으로 보낸다 보내서 거기서 검색해서 쓴다 혹은 AWS Cloud Watch를 사용한다. 로그는 비정형이다보니까 스키마가 없다그러니까 NoSQL을 사용한다.
Nest에서는 export default를 쓰지않고 export만을 쓰는게 컨벤션이다 그래서 가져올때도 import { test } from blabla 이렇게 가져온다
interface보다도 class를 많이쓴다 타입스크립트에서 Interface는 컴파일 하고나면 없어져버리는데 그래서 런타임시 체크가어렵다, 반면 클래스는 컴파일후에도 남는다.
@Body → request.body
@Query → request.query
@Param → request.params
response.locals => response끼리 공유하는 데이터
API EndPoint 만들때 항상 주의깊게 만들자
typeof null === ‘object’이거 자바스크립트만들때 실수한건데 20년째 못바꾸고있다.
express에서 swagger 자동화를 못하는 이유는 첫째로 타입이 없어서이다.
swagger 문서를 자동으로 만든다는게 내부적으로 정말 복잡한 일이다. 왜냐하면 요청, 응답 이런것들의 정보들을 다 알아야하는데 express는 자유도가 높기때문에 타입스크립트가 어떤게 요청이고, 어떤게 응답이고 이런걸 파악하는데 한계가온다.
DTO를 Class로 하는게 좋은이유가 나중에 Joi나 Validate를 한번에 할수 있다.
DI받은 객체들은 private로 하는게 좋다 왜냐하면 DI를 받았다는것은 받아서 거기서만 쓰겠다는건데 그걸 다시 public으로 해서 다른곳에서 쓸거면 DI 해준 의미가 없다
TypeORM이 Sequelize보다 TypeScript 지원이 더 좋다
typeorm-model-generator로 model을 자동으로 생성해주는 패키지를 사용한다.
TypeORM에 한해서 Entity가 테이블에 대응되는 개념이라고보면된다
npx typeorm-model-generator -h localhost -d db이름 -u root -x 패스워드 -e 엔진이름
디비에 이미 테이블이 있으면 그거가지고 알아서 Entity를 만들어주고 반대로 Entity를 만들고나서 TypeORM으로 테이블 생성이 가능하다
진짜로 지우는게아니라 가짜로 지우는척하는것을 SoftDelete 기법이라고 한다.
erdCloud.com
npm i @nestjs/typeorm typeorm mysql2
npm outdated // 최신버전인지 확인
TypeORM Seeding
- 초기 데이터를 넣어줌
- 테스트 할때 가짜데이터 넣어서 실험하다가 drop해버리고 이런과정을 반복하기위해서 사용
- factory.ts를 사용함
Faker
- 가짜데이터 생성 Library
TypeORM Migration
- TODO
throw는 return기능을 수반한다.