Nest

pipe는 pipetransform interface를 받는다.

Dry 원칙 (don't repeat yourself) : 두 번 같은 코드를 짜지 말자
Kiss 원칙 (Keep it simple, stuipd) : 큰 프로젝트를 최소한 작은 단위로 쪼개서, 이를 합친다.
Yagni 원칙(You ain't gonna need it) : 결국 쓸데 없을 테니 간단한 기능으로 적은 컴포넌트로 문제를 해결하자

가드
미들웨어 다음, 인터셉터 파이프 전에 실행됨
middleware와 차이점은 어디서 호출 되었는지를 알 수 있다는 것. 그래서 인증 구현에 훨씬 좋음

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(
    context: ExecutionContext,
  ): boolean | Promise<boolean> | Observable<boolean> {
    const request = context.switchToHttp().getRequest();
    return validateRequest(request);
  }
}

can activate 함수를 구현해야 하고, Execution Context에서 어디서 작동한 가드인지 알 숭 ㅣㅆ음
false시 프로그램 예외
@Useguards. 데코레이터로 사용 가능

@Post()
@SetMetadata('roles', ['admin'])
async create(@Body() createCatDto: CreateCatDto) {
  this.catsService.create(createCatDto);
}

이게 유용해 진다. 하지만 이것도 유효는 하지만 권장되지는 않는데,

import { SetMetadata } from '@nestjs/common';

export const Roles = (...roles: string[]) => SetMetadata('roles', roles);

이 부분이 훨씬 더 깔끔해진다.
Roles라는 커스텀 데코레이터를 만들어서 처리하는 방법이다.
Reflector 라는 @nestjs/core 에 있는 헬퍼 클래스를 받아서, 이를 활용해 커스텀 메타데이터를 접근해서 이를 활용해서 간단한 인증을 구현할 수 있다.
출처

관점 지향 프로그래밍
어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누고, 이를 이용해 모듈화 한다.
흩어진 관심사(crosscutting concerns)는 다른 부분에서 계속 쓰이는 그냥 반복. 이를 잘 줄잊아 라는 느낌

객체 지향 프로그래밍의 관점에서는 로깅, 보안 등 여러 기능들이 여러 클래스에 흩어져서 존재한다.
클래스가 단일 책임을 가지도록 분리했기에, 각 모듈의 응집도가 높아지고, 결합도가 낮아진다. 클래스를 변경하는 이유는 오직 어플리케이션의 한 부분이 변경되었을 때이다. 그 파급효과는 당연히 전체로 퍼져나가지 않는다.
객체 지향은 유저 받고=>로그 남기고=>인증 하고=>보안 검증=>요청 처리=>반환 느낌으로 되는 여러가지의 기능이 있는데, 다른 기능에서는 인증, 보안 코드가 반복되는 문제가 생긴다. 이를 줄이기 위한 방법중 하나가 관점 지향 프로그래밍이다.
하나의 기능인 보안, 로그 를 다 묶어서 처리하되, 당연히 현실적이지 않으니 decorator 로 의존성 주입을 하는 방식으로 인스턴스를 받든, 클래스를 받든, 값을 받든, 조건을 받든 해서 훨씬 중복을 줄이는 방향으로 쓸 수 있을 것이다.

인터셉터
하는 일
메서드 실행 전/후에 추가 로직 바인딩
함수가 반환한 결과를 변환
함수가 던진 예외를 변환
기본적인 함수 동작을 확장
특정 조건에 따라 함수를 완전히 override
그냥 단순하게 controller에서 return "data"만 해도 {code:SUCCESS,data:"data"}같은 처리를 알아서 해주는게 훨씬 간단해짐

nest 강좌 듣기
zerocho...비싸다..
nodejs는 package.json부터 보러 간다.

req, res를 service가 모르기에 조금 더 역할을 분리한다고 느끼면 됨.
controller는 req,res를 신경 쓰고, service는 그냥 순수하게 함수가 된다. 조금 더 독립적임. 이에 따라서 테스팅이 조금 더 쉬워짐(req,res, next mocking의 과정이 없어진다는게 큰 장점)

express도 물론 가능하지만, 훨씬 직접 분리 과정이 없고, 있고의 차이가 사람마다 다르기 때문에 협업의 과정이 훨씬 엄격하게 지키기 좋음.

nest template

tsconfig 에다가 "esModuleInterop": true
장점은 import as name from "name"에서 as 가 생략 가능함
tsconfigRootDir: __dirname,
이거를 .eslintrc.js 에 parseOptions 안에 넣어주면 parseError eslint에러가 삭제됨.

nest는 res.json()같은 처리를 전혀 안 해도 된다는 어마어마한 장점이 있음
configure은 configure을 import해서 사용해야 한다는 점. imports: [ConfigModule.]
forRoot나, forRegister, 같은게 뒤에 붙는 경우는 보통 세팅을 위해서 하는 것
ConfigModule.forRoot()를 import해두면, .env를 쓸 수 있음
이때 forRoot 안에 { isGlobal: true } 를 넣으면 전역 속성도 가능
@nestjs/config를 하면 여기서 .env 기능 사용 가능
process.env. 라고 하는 부분마저도 생략할 수 있다.