AWS RDS - DBMS 종류가 아님/ RDS - DBMS 세팅 된 컴퓨터를 대여해주는 것
AWS = RDS 서비스 / AWS가 컴퓨터 하나를 공짜로 대여해주는 것 - RDS/EC2
NestJS는 모듈 단위로 움직임
app.module은 흩어져 있는 모듈을 한번에 모아주는 역할을 함
(app.module이 꼭 있어야하는 건 아님 그저 최상위 모듈일 뿐)
module - controller / provider(=서비스 로직)
프로바이더 = 데이터 처리 비즈니스 로직 처리를 모두 합쳐서 처리함
npm run start, start:dev의 차이점
- start: 직접 build를 해야함(타입스크립트로 작성한 것을 수동으로 npm build를 통해
수동적으로 build를 해야함)
- start:dev: 저장을 했을 때 자동으로 build와 서버를 시작시켜줌
(주의점: 컴 구리면 렉 심하게 걸림)
nest g mo boards를 하면 자동으로 boards 폴더를 만들어주고 그 안에 module파일을 만들어줌
(app.module에 자동적으로 임포트가 됨)
nest g mo boards, nest g s boards, nest g co boards(모듈, 서비스, 컨트롤러)
nest g class boards/board.entity --no-spec
(클래스를 생성해주기도 하는데, 이런경우에는 어디에 생성해줄지 위치까지 정해줘야함)
1. board.entity에 interface로 model을 만들어 줌
(interface로 명시했다는 것은 타입만 적어줬다는 것)
2. boards.controller에 service를 주입하기 위해 constructor로 주입시킴
- constructor(private readonly boardsService:BoardsService){}
@Get('/')
getAllBoards():Board[] {
return this.boardsService.getAllBoards()
}
3. boards.service에 getAllBoards 메서드 작성
- export class BoardsService {
boards: Board[ ]
constructor() {
this.boards = new Array<Board>();
}
getAllBoards(): Board[] {
return this.boards;
}
4. createBoard.dto.ts 파일에 dto를 만들어준다.
@Body() createBoardDto: CreateBoardDto
@Body를 사용하여 Dto를 활용
(npm i class-validator 필요함)
파이프(pipes)
- dto에 있는 validator는 controller에 @UsePipes(ValidationPipe)가 없으면 정상작동 하지 않는다.
그동안 우리가 컨트롤러에 @UsePipes를 안써줬던 이유
- main.ts에 app.useGlobalPipes(
new validationPipe({
transform: true,}),
);
를 써줬기 때문
npm i @nestjs/typeorm typeorm mysql으로 typeORM 사용을 위해 인스톨함
app.module에 내가 typeORM을 쓸 거라고 명시를 해둔다.
npm i @nestjs/config 데이터 베이스에 접근하는 정보를 평문으로 노출시키기 싫어서 씀
ConfigModule.forRoot({
// Load and parse .env file(s) here
isGlobal: true, // Makes the config globally available
}),
TypeOrmModule.forRootAsync({
useFactory: (configService: ConfigService) => ({
type: 'mysql',
host: configService.get('DATABASE_HOST'),
port: +configService.get('DATABASE_PORT'),
username: configService.get('DATABASE_USER'),
password: configService.get('DATABASE_PASSWORD'),
database: configService.get('DATABASE_NAME'),
entities: [],
synchronize: true,
}),
inject: [ConfigService],
AuthGuard(jwt 토큰 검증하는 가드)
라이프 사이클 관점에서는 가드와 파이프는 다르다.
가드(인가)를 지나고 파이프를 만남
인증과 인과 때문에 왜 모듈을 만들어야하는가?
- 인증과 인과도 비즈니스 로직이라는 것이 있음.
네스트가 모듈 단위로 움직이기 때문임.
jwt 라이브러리를 활용하기 위해 어스 모듈에
JwtModule.register를 임포트해준다.
passport를 사용하면 Strategy를 만들어줘야함(공식문서 그냥 때려박아줌)
passport를 사용하면 JwtStrategy만 만들어주면 된다.
auth.module에 임포트만 하면(+ providers에 JwtStrategy 등록) 따로 AuthGuard를 만들어주지 않아도 바로 사용할 수 있음
userService에서 jwt서비스를 쓸 수 있게 생성자에서 private readonly jwtService로 추가해줌
userModule 임포트에 JwtModule을 추가해준다.
=> userController에서 AuthGuard를 사용이 가능해진다.
AuthGuard는 passport에 속해있음. AuthGuard에 영향을 주는 것은 jwtStrategy임
우리는 jwtStrategy를 만드는 것 만으로도 passport라는 라이브러리 덕분에 AuthGuard를 사용할 수 있고,
NestJS의 규칙에 따라 가드를 사용할 때는 @UseGuards 데코레이터를 사용해야한다.
=>@UseGuards()