Nest.js(4)

MySQL 설정

💡 ORM이란?

ORM(Object-Relational Mapping)은 데이터베이스의 관계를 객체로 바꾸어 개발자가 OOP로 데이터베이스를 쉽게 다룰 수 있도록 해 주는 도구입니다. SQL문을 그대로 코드에 기술하고 그 결과를 쿼리셋으로 다루는 방식에서 세부 쿼리문을 추상화하는 것으로 발전하였습니다. 개발자는 ORM에서 제공하는 인터페이스를 통해 일반적인 라이브러리를 호출하듯 DB에 데이터를 업데이트하고 조회할 수 있습니다.

데이터베이스 설정

DBeaver와 MySql를 이용해서 개발 한다.

ORM 가능한 기능중에 TypeORM 을 사용합니다.

 

@nestjs/typeorm 패키지에서 제공하는 TypeOrmModule을 이용하여 DB에 연결할 수 있습니다.

...
import { TypeOrmModule } from '@nestjs/typeorm';

@Module({
  imports: [
        ...
    TypeOrmModule.forRoot({
      type: 'mysql',
      host: 'localhost',
      port: 3306,
      username: 'root',
      password: 'test',
      database: 'test',
      entities: [__dirname + '/**/*.entity{.ts,.js}'],
      synchronize: true,
    }),
  ],
})
export class AppModule {}

 

- type: TypeOrmModule이 다루고자 하는 데이터베이스의 타입입니다. 우리는 MySQL을 이용합니다.

- host: 연결할 테이터베이스 호스트 주소 입력

- port: 데이터베이스에서 연결을 위해 열어놓은 포트번호입니다. MySQL은 기본값으로 3306번 포트를 사용합니다.

- username, password : 비번 및 아이디

- database: 연결하고자 하는 데이터베이스 스키마 이름입니다. 앞서 만든 test 스키마를 사용합니다.

- entities: 소스 코드 내에서 TypeORM이 구동될 때 인식하도록 할 엔티티 클래스의 경로를 지정합니다.

- synchronize: 서비스 구동시 소스코드 기반으로 데이터베이스 스키마를 동기화 할지 여부입니다. 로컬환경에서 구동할때는 개발의 편의를 위해 true로 합니다. ( 소스 코드 변경하면 데이터베이스가 변경된다. )

 

⚠️ synchronize 옵션을 true로 하면 서비스가 실행되고 데이터베이스가 연결될 때 항상 데이터베이스가 초기화 되므로 절대 프로덕션에는 true로 하지 마세요!

 

TypeOrmModule.forRoot 함수에 전달하는 TypeOrmModuleOptions 객체를 좀 더 자세히 살펴보겠습니다.

export declare type TypeOrmModuleOptions = {
    retryAttempts?: number;
    retryDelay?: number;
    toRetry?: (err: any) => boolean;
    autoLoadEntities?: boolean;
    keepConnectionAlive?: boolean;
    verboseRetryLog?: boolean;
} & Partial<ConnectionOptions>;

• retryAttempts: 연결시 재시도 회수. 기본값은 10입니다.
• retryDelay: 재시도 간의 지연 시간. 단위는 ms이고 기본값은 3000입니다.
• toRetry: 에러가가 났을 때 연결을 시도할 지 판단하는 함수. 콜백으로 받은 인자 err 를 이용하여 연결여부를 판단하는 함수를 구현하면 됩니다.
• autoLoadEntities: 엔티티를 자동 로드할 지 여부.
• keepConnectionAlive: 애플리케이션 종료 후 연결을 유지할 지 여부.
• verboseRetryLog: 연결을 재시도 할 때 verbose 에러메시지를 보여줄 지 여부. 로깅에서 verbose 메시지는 상세 메시지를 의미합니다.

TypeOrmModuleOptions는 위에서 설명한 타입과 ConnectionOptions 타입의 Partial타입을 교차(&)한 타입입니다. Partial 제네릭 타입은 선언한 타입의 일부 속성만을 가질 수 있도록 하는 타입입니다. 교차 타입은 교차시킨 타입의 속성들을 모두 가지는 타입입니다. ConnectionOptions의 정의를 보면 Nest가 지원하는 데이터베이스가 어떤 것들인지 알 수 있습니다. MySQL 외에도 PostgreSQL, MsSQL, Oracle 등 뿐 아니라 Native, Mongo, Amazon Aurora도 지원합니다.

ormconfig.json 활용

Nest는 데이터베이스를 연결는 또 다른 방법을 제공합니다. 루트 디렉토리에 ormconfig.json파일이 있다면 TypeOrmModule.forRoot()에 옵션 객체를 전달하지 않아도 됩니다. 여기서 주의할 점이 JSON파일에는 엔티티의 경로를 __dirname으로 불러올 수 없기 때문에 빌드 후 생성되는 디렉토리이름인 dist를 붙여주어야 합니다.

• ormconfig.json

{
  "type": "mysql",
  "host": "localhost",
  "port": 3306,
  "username": "root",
  "password": "test",
  "database": "test",
  "entities": ["dist/**/*.entity{.ts,.js}"],
  "synchronize": true
}

import { TypeOrmModule } from '@nestjs/typeorm';

@Module({
  imports: [
    TypeOrmModule.forRoot(),
  ],
})
export class AppModule {}

회원 가입을 요청한 유저의 정보 저장하기

Nest는 리퍼지토리 패턴을 지원합니다. 리포지토리는 데이터 원본에 액세스하는 데 필요한 논리를 캡슐화하는 클래스 또는 구성 요소입니다. 리포지토리는 공통 데이터 액세스 기능에 집중해 더 나은 유지관리를 제공하고 도메인 모델 계층에서 데이터베이스에 액세스하는 데 사용되는 기술이나 인프라를 분리합니다.

• user.entity.ts

import { Column, Entity, PrimaryColumn } from 'typeorm';

@Entity('User')
export class UserEntity {
  @PrimaryColumn()
  id: string;

  @Column({ length: 30 })
  name: string;

  @Column({ length: 60 })
  email: string;

  @Column({ length: 30 })
  password: string;

  @Column({ length: 60 })
  signupVerifyToken: string;
}

서버를 구동하면 DB 에 테이블이 생성된다. 동기화 옵션을 true 로 해두었기 때문이다.

트랜잭션 적용

TypeORM에서 트랜잭션을 사용하는 방법은 3가지가 있습니다.

• QueryRunner를 이용해서 단일 DB 커넥션 상태를 생성하고 관리하기
• transaction 객체를 생성해서 이용하기
• @Transaction, @TransactionManager, @TransactionRepository 데코레이터를 사용하기

QueryRunner 클래스를 사용하는 방법

QueryRunner를 이용하면 트랜잭션을 완전히 제어할 수 있습니다. Connection  주입합니다.

...
import { Connection, ... } from 'typeorm';

@Injectable()
export class UsersService {
  constructor(
        ...
        private connection: Connection,
  ) { }
    ...
}

이제 Connection 객체에서 트랜잭션을 생성할 수 있습니다. 유저를 저장하는 로직에 트랜잭션을 걸어봅시다.

private async saveUserUsingQueryRunner(name: string, email: string, password: string, signupVerifyToken: string) {
  const queryRunner = this.connection.createQueryRunner();

  await queryRunner.connect();
  await queryRunner.startTransaction();

  try {
    const user = new UserEntity();
    user.id = ulid();
    user.name = name;
    user.email = email;
    user.password = password;
    user.signupVerifyToken = signupVerifyToken;

    await queryRunner.manager.save(user);

    // throw new InternalServerErrorException(); // 일부러 에러를 발생시켜 본다

    await queryRunner.commitTransaction();
  } catch (e) {
    // 에러가 발생하면 롤백
    await queryRunner.rollbackTransaction();
  } finally {
    // 직접 생성한 QueryRunner는 해제시켜 주어야 함
    await queryRunner.release();
  }
}

- 주입받은 Connection 객체에서 QueryRunner를 생성합니다.

- QueryRunner에서 DB에 연결 후 트랜잭션을 시작합니다.

- 정상 동작을 수행했다면 트랜잭션을 커밋하여 영속화시킵니다.

- DB 작업을 수행한 후 커밋을 해서 영속화를 완료합니다.

- 이 과정에서 에러가 발생하면 직접 롤백을 수행합니다.

- finally구문을 통해 생성한 QueryRunner 객체를 해제합니다. 생성한 QueryRunner는 해제시켜 주어야 합니다.

transaction 객체를 생성해서 이용하는 방법

transaction 메소드는 EntityManager를 콜백으로 받아 사용자가 어떤 작업을 수행할 함수를 작성할 수 있도록 해 줍니다.

private async saveUserUsingTransaction(name: string, email: string, password: string, signupVerifyToken: string) {
  await this.connection.transaction(async manager => {
    const user = new UserEntity();
    user.id = ulid();
    user.name = name;
    user.email = email;
    user.password = password;
    user.signupVerifyToken = signupVerifyToken;

    await manager.save(user);

    // throw new InternalServerErrorException();
  })
}

@Transaction, @TransactionManager, @TransactionRepository 이용

₩₩

마이그레이션

만약 이전에 저장해 둔 데이터가 현재의 도메인 구조와 다르다면 모든 데이터의 값을 수정할 일도 생깁니다. 이런 과정 역시 마이그레이션이라고 부릅니다.  쉽게 이야기 하면 현재 작성된 DB 스키마와 실제 DB 스키마를 sync해주는 것이다

- 첫째 마이그레이션을 위한 SQL문을 직접 작성하지 않아도 됩니다. 

- 만약 마이그레이션이 잘못 적용되었다면 마지막 적용한 마이그레이션 사항을 되돌리는 작업도 간단히 명령어로 수행할 수 있습니다. 

- 물론 데이터의 값을 변경하는 마이그레이션이라면 원복하는 코드를 직접 작성해야 하기는 합니다. 

- 롤링 업데이트가 가능한 마이그레이션이 아니라면 적용하기 전에 DB를 백업하는 것을 잊지 말아야 합니다

- TypeORM 마이그레이션을 이용하면 마이그레이션 코드를 일정한 형식으로 소스 저장소에서 관리할 수 있습니다. 즉 데이터베이스의 변경점을 소스 코드로 관리할 수 있다는 뜻입니다

- TypeORM 마이그레이션을 적용하여 마이그레이션 이력을 관리할 수 있습니다. 언제 어떤 마이그레이션이 일어났는지를 특정 테이블에 기록하고, 필요할 경우 처음부터 순서대로 다시 수행할 수도 있습니다.

미들웨어

Nest의 미들웨어는 기본적으로 Express의 미들웨어와 동일합니다. Express 문서에는 미들웨어가 다음과 같은 동작을 수행할 수 있다고 기술되어 있습니다.

• 어떤 형태의 코드라도 수행할 수 있습니다.
• 요청과 응답에 변형을 가할 수 있습니다.
• 요청-응답 주기를 끝낼 수 있습니다.
• 여러 개의 미들웨어를 사용한다면 next()로 호출 스택상 다음 미들웨어에게 제어권을 전달합니다.

미들웨어를 활용하여 다음과 같은 작업들을 수행합니다.

• 쿠키 파싱: 쿠키를 파싱하여 사용하기 쉬운 데이터 구조로 변경합니다. 이를 이용하면 라우터 핸들러가 매번 쿠키를 파싱할 필요가 없습니다.
• 세션 관리: 세션 쿠키를 찾고, 해당 쿠키에 대한 세션의 상태를 조회해서 요청에 세션 정보를 추가합니다. 이를 통해 다른 핸들러가 세션 객체를 이용할 수 있도록 해 줍니다.
• 인증/인가: 사용자가 서비스에 접근 가능한 권한이 있는지 확인합니다. 단, Nest는 인가를 구현할 때 가드(Guard)를 이용하도록 권장하고 있습니다.
• 본문(body) 파싱: 본문은 POST/PUT 요청으로 들어오는 json 타입뿐 아니라 파일 스트림과 같은 데이터도 있습니다. 이 데이터를 유형에 따라 읽고 해석한 다음 파라미터에 넣는 작업을 합니다. 앞서 컨트롤러 장에서 보았던 본문은 이렇게 분석된 결과가 포함되어 있습니다.

미들웨어는 함수로 작성하거나 NestMiddleware 인터페이스를 구현한 클래스로 작성할 수 있습니다. 들어온 요청에 포함된 정보를 로깅하기 위한 Logger를 미들웨어로 구현해 봅시다.

import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log('Request...');
    next();
  }
}

미들웨어를 모듈에 포함시키기 위해서는 해당 모듈은 NestModule 인터페이스를 구현해야 합니다. NestModule에 선언된 configure함수를 통해 미들웨어를 설정합니다.

• logger.middleware.ts

import { MiddlewareConsumer, Module, NestModule } from '@nestjs/common';
import { LoggerMiddleware } from './logger/logger.middleware';
import { UsersModule } from './users/users.module';

@Module({
  imports: [UsersModule],
})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer): any {
    consumer
      .apply(LoggerMiddleware)
      .forRoutes('/users');
  }
}

/users 경로로 들어오는 요청을 수행해 보면 콘솔에 Request... 이 찍히는 걸 확인할 수 있습니다.

MiddlewareConsumer

이전 코드에서 confiure 메서드에 인자로 전달된 MiddlewareConsumer 객체를 이용해서 미들웨어를 어디에 적용할 지 관리할 수 있습니다. apply 메소드의 원형은 다음과 같습니다.

exclude함수는 예상하듯이 미들웨어를 적용하지 않을 라우팅 경로를 설정합니다.

...
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer): any {
    consumer
      .apply(LoggerMiddleware, Logger2Middleware)
      .exclude({ path: 'users', method: RequestMethod.GET },)
      .forRoutes(UsersController)
  }
}

전역으로 적용하기

함수로 정의된 미들웨어를 다시 만들어 봅시다.

import { Request, Response, NextFunction } from 'express';

export function logger3(req: Request, res: Response, next: NextFunction) {
  console.log(`Request3...`);
  next();
};

그리고 main.ts에서 적용합니다.

import { logger3 } from './logger3/logger3.middleware';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.use(logger3);
  await app.listen(3000);
}
bootstrap();

exclude 옵션을 다시 풀고 요청을 보내면 logger3 미들웨어가 먼저 적용되는 것을 알 수 있습니다.

💡 함수로 만든 미들웨어의 단점은 DI 컨테이너를 사용할 수 없다는 것입니다. 즉, 프로바이더를 주입받아 사용할 수 없습니다.

JWT ( Guard )

- 인증은 요청자가 자신이 누구인지 증명하는 과정입니다.

- 인가(Authorization)는 인증을 통과한 유저가 요청한 기능을 사용할 권한이 있는지를 판별하는 것을 말합니다

 

미들웨어는 실행 컨텍스트(ExecutionContext)에 접근하지 못합니다. 가드는 실행 컨텍스트 인스턴스에 접근할 수 있어 다음 실행될 작업을 정확히 알고 있습니다.

가드를 이용한 인가

가드는 CanActivate 인터페이스를 구현해야 합니다.

import { CanActivate, ExecutionContext, Injectable } 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 this.validateRequest(request);
  }

  private validateRequest(request: any) {
    return true;
  }
}

실행 컨텍스트

canActivate 함수는 ExecutionContext 인스턴스를 인자로 받습니다. ExecutionContext는 ArgumentsHost를 상속받는데, 요청과 응답에 대한 정보를 가지고 있습니다. 우리는 http로 기능을 제공하고 있으므로 인터페이스에서 제공하는 함수 중 switchToHttp() 함수를 사용하여 필요한 정보를 가져올 수 있습니다.

가드 적용

가드를 적용하는 방법은 앞서 예외 필터를 적용하는 것과 유사합니다. 컨트롤러 범위 또는 메서드 범위로 적용하고자 한다면 @UseGuards(AuthGuard) 와 같이 사용하면 됩니다. AuthGuard 인스턴스의 생성은 Nest가 맡아서 합니다. 만약 여러 종류의 가드를 적용하고 싶다면 쉼표로 이어 선언하면 됩니다.

@UseGuards(AuthGuard)
@Controller()
export class AppController {
  constructor(private readonly appService: AppService) { }

  @UseGuards(AuthGuard)
  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

가드를 이용한 인가 처리

컨트롤러의 “유저 정보 조회” 구현을 다시 살펴봅시다.

@Get(':id')
async getUserInfo(@Headers() headers: any, @Param('id') userId: string): Promise<UserInfo> {
  const jwtString = headers.authorization.split('Bearer ')[1];

  this.authService.verify(jwtString);

  return this.usersService.getUserInfo(userId);
}

현재 구현방식은 헤더에 포함된 JWT 토큰의 유효성을 검사하는 로직을 모든 엔드포인트에 중복 구현해야 합니다. 이는 매우 비효율적이고 DRY 원칙에도 위배됩니다. 우리는 Nest에서 제공하는 가드를 이용하여 이를 핸들러 코드에서 분리해 봅시다.

일단 앞서 예시로 만든 것과 같이 AuthGuard를 적용해 보겠습니다.

import { Request } from 'express';
import { Observable } from 'rxjs';
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { AuthService } from './auth/auth.service';

@Injectable()
export class AuthGuard implements CanActivate {
  constructor(private authService: AuthService) { }

  canActivate(
    context: ExecutionContext,
  ): boolean | Promise<boolean> | Observable<boolean> {
    const request = context.switchToHttp().getRequest();
    return this.validateRequest(request);
  }

  private validateRequest(request: Request) {
    const jwtString = request.headers.authorization.split('Bearer ')[1];

    this.authService.verify(jwtString);

    return true;
  }
}

validateRequest 메서드에 앞서 컨트롤러에 구현된 로직을 옮겨왔습니다. 가드는 준비되었으니 AuthGuard를 적용해야 합니다. 전역으로 적용하게 되면 회원가입, 로그인 등 액세스 토큰 없이 요청하는 기능은 사용할 수 없으므로 회원 조회 엔드포인트에만 적용하겠습니다. 물론 컨트롤러를 분리시키고, 분리된 컨트롤러에 적용해도 됩니다.