nest 3일차

테스트코드

• controller test code에서는 repository를 모킹할 필요가 없음. controller는 요청을 받아서 service에 위임하기 때문에 service를 잘 호출하는지만 확인하면 된다.
• service test code는 repository의 리턴을 모킹하고 어떻게 반응하는지에 대해서만 테스트한다.
  • 빈 객체일때 바로 리턴하는건 save없이 service에서 얼리리턴하는게 좋음. DB 업데이트 리소스를 줄이는 것이 좋다.
• dto test code: 입력값에 대한 검증만 함
  • class-validator의 validate return 배열인 에러배열을 확인
    • 실패: 예상값과 같은지 확인
    • 성공: 에러배열.length === 0

try catch

• nest에서 try catch 특별한 경우 아니면 안붙혀도 됨. 일반적인 CRUD에서는 NestJS 기본 처리에 맡기면 됨
  • try-catch가 필요한 경우:
    • 예외를 다르게 변환하고 싶을 때
    • 예외 발생 후 추가 로직이 필요할 때 (로깅 등)

Entity

• id, createdAt, updatedAt은 base entity로 만들고 각 도메인에서 base entity를 확장한다.
  • abstract: 직접 사용하지 말고, 상속해서 사용하도록 강제 (공통필드 제공)

import {
  CreateDateColumn,
  PrimaryGeneratedColumn,
  UpdateDateColumn,
} from 'typeorm';

export abstract class AbstractEntity {
  @PrimaryGeneratedColumn()
  id: number;

  @CreateDateColumn()
  createdAt: Date;

  @UpdateDateColumn()
  updatedAt: Date;
}

 

ParseIntPipe

• controller 전용 데코레이터이다.
  • HTTP요청에서 string으로 받아서 controller밖에서 number로 변환 하고, controller에 넣는다.
• +id는 "abc" 같은 입력이 오면 NaN이 되고, 자동으로 400 에러를 반환

OpenAPI

백엔드에서 하는일은 json만들어주는것뿐이었음

프론트에서 orval쓰든 openapi쓰든 그건 알아서

 

Foreign Key (외래키)

다른 테이블의 row를 참조하는 컬럼

id	bookId	userId
1	1	1
2	1	2
3	3	1

여기서 FK는 bookId, userId다 

 

FK는 항상 @ManyToOne쪽에 생긴다. 

ex) 유저 한명의 대출기록은 여러개임 -> 대출 과 유저는 ManyToOne임. -> 각 loan마다 userId를 달아준다.

-> loan에는 userId, bookId가 자동생성된다.

 

oneToMany쪽에는 안생긴다. 유저 1명이 대출10개면 User 테이블에 loanId 10개를 넣을 수 없으니까.

 

컨트롤러 배치 기준

loan container에 @Get: /users/:userId/loans 를 작성한 이유

api가 반환하는게 대출 데이터(Loan)이기 때문. 유저의 대출 목록이니까 대출 도메인의 책임으로 본다.

반환 데이터 기준으로 배치

 

=> url 기준이 아닌 데이터 처리 기준

 

TypeORM

• ORM: 객체와 DB 테이블을 자동으로 연결해주는 도구
  • SQL몰라도 TS코드로 DB조작할 수 있게 해줌
  • Entity:테이블, 클래스 하나가 DB테이블 하나
  • Repository: 테이블 조작 도구.
    • 각 Entity마다 생기는 CRUD도구
• Create: 메모리에 객체만 만듬
• Save: 실제 DB에 저장
• isNull: where is null 연산자
• count: 엔티티 로드 없이 개수만 조회
• shychronize 옵선: 프로덕션에서 true로 두면 안됨. 프로덕션에선 migration해서 DB관리