백엔드 Nest.js 코드 베이스 - 기본구조

Nest.js 코드 베이스 - 기본 구조

1. [기본 구조](https://velog.io/@testtesttest/%EA%B0%80%EC%A0%9CNest.js-%EC%8B%A4%EB%AC%B4-boilerplate) [ current ]
2. [Serialization](https://velog.io/@testtesttest/testtest2)
3. [에러 처리](https://velog.io/@testtesttest/SI%EB%A5%BC-%EC%9C%84%ED%95%9C-%EB%B0%B1%EC%97%94%EB%93%9C-Nest.js-%EC%BD%94%EB%93%9C-%EB%B2%A0%EC%9D%B4%EC%8A%A4-2%ED%8E%B8-%EC%97%90%EB%9F%AC-%EC%B2%98%EB%A6%AC)
4. SI를 위한 백엔드 Nest.js 코드 베이스 - logger

속편 목록: 자주쓰는 인프라 모듈들 Logger, Cache, MessageQueue, Socket, FileUpload(S3)

1. 새로운 프로젝트 시작할때마다 중복되는 코드가 많다. (시간 절약이 곧 비용절약.)
2. 현재 개발자들에게 제공하는 코드 자율성이 너무 크다.
  => 개발 리드가 바빠지다보면 코드 퀄리티가 낮아질 수 있다.
  => 유지보수할때 힘들어진다.
3. 긴급해서 다른 개발자들이 프로젝트에 참여할때 러닝커브를 줄여야한다.

프로젝트 구조

Root
  ⌙.husky (lint, prettier, commitlint...)
  ⌙src
    ⌙user (domain module)
      ⌙user.controller.ts
      ⌙user.service.ts
      ⌙user.repository.ts
      ⌙dtos
        ⌙create-user.dto.ts
        ⌙find-user.dto.ts
      ⌙entities
        ⌙user.entity.ts
        ⌙company.entity.ts
        ⌙employee.entity.ts
      ⌙constants
        ⌙user.constant.ts
        ⌙company.constant.ts
      ⌙interfaces
        ⌙user.interface.ts
        ⌙company.interface.ts
      ⌙middlewares
        ⌙some-specific-middleware.middleware.ts
    ⌙...OtherDomainModules (like employment, product...)
    ⌙core
      ⌙authentication (guards)
      ⌙req-res.wrapper.ts
      ⌙pagination.ts
      ⌙infinite-scroll.ts
      ⌙exceptions
      ⌙interfaces
      ⌙middlewares
      ⌙pipes
      ⌙dtos
    ⌙shared (Not injecting module/static methods)
      ⌙date.util.ts

    // 아래는 다음글을 참고해주세요.
	⌙infrastructure (Injecting module)
      ⌙cache
      ⌙message-queue
      ⌙socket
      ⌙file-upload
      ⌙logger
      ⌙notification(firebase)

도메인 모듈의 기본 구조.

// after running command "nest g resource user", it provide below files.
⌙user
  ⌙dto
    ⌙create-user.dto.ts
    ⌙update-user.dto.ts
  ⌙entities
    ⌙user.entity.ts
  ⌙user.module.ts
  ⌙user.controller.ts
  ⌙user.service.ts
  ⌙user.entity.ts

  // And below folder and file are Additionals on our codebase.
  ⌙user.repository.ts
  ⌙constants
  ⌙interfaces
  ⌙middlewares

Controller Layer

@ApiTags('user')
@Controller(`${API_VERSION.V1}/user`)
export class UserController {
  constructor(
    private readonly userService: IUserService,
    ...) {}

  @ApiVersion('1')
  @ApiOperation({
    summary: 'Sign up',
  })
  @ApiResponse({
    status: HttpStatus.CREATED,
    description: 'Success signup',
    type: User,
  })
  @ApiResponse({
    status: HttpStatus.UNPROCESSABLE_ENTITY,
    description: 'When the required parameter not entered',
  })
  @HttpCode(HttpStatus.CREATED)
  @Post('signup')
  async signup(@Body() body: CreateUserDto): Promise<IUser> {
    const createdUser = await this.userService.signup(body);
  }
}

Service Layer

1. 모든 비지니스 로직은 service layer에 존재해야합니다.2. 메서드를 못나누겠다면 "트랜잭션 단위"로 자른다.3. 개발자의 자율성이 부여된 곳은 오직 service layer입니다.

1. 모든 비지니스 로직은 service layer에 존재해야합니다.

// user.controller.ts
@HttpCode(HttpStatus.CREATED)
@Post('signup')
async signup(@Body() body: SignupBodyDto) {
	const result = await this.authService.checkOtp(req.body.otp)

    // Throwing exception on the controller. This is business logic
    if (!result) throw new BadRequestException(API_EXCEPTION.WRONG_OTP);

  	const validOrNot = await this.checkService.checkSomethingValid(req.body);

    if (!validOrNot) throw new UnauthorizedException(API_EXCEPTION.NOT_VALID);

    return this.userService.signup(req.body.name, req.body.phoneNumber);
}

// user.service.ts
...
async checkOtp(phoneNumber, req.body.otp) {
	return await this.cacheService.matchSavedOtp(phoneNumber, req.body.otp);
}

async checkSomethingValid(req.body) {
    return await this.~
}

// user.controller.ts
@HttpCode(HttpStatus.CREATED)
@Post('signup')
async signup(@Body() body: SignupBodyDto) {
    await this.authService.checkOtp(req.body.phoneNumber, req.body.otp)

    await this.checkService.checkSomethingValid(req.body);

    return this.userService.signup(req.body.name, req.body.phoneNumber);
}

// user.service.ts
...

// Throw exception at the place working directly
async checkOtp(phoneNumber, req.body.otp) {
	const result = await this.cacheService.matchSavedOtp(phoneNumber, req.body.otp);
    if (!result) throw new BadRequestException(API_EXCEPTION.WRONG_OTP);
}

async checkSomethingValid(req.body) {
    const result =  await this.~
	if (!result) throw new UnauthroziedException(API_EXCEPIOTN.NOT_VALID);
}

2. 메서드를 못나누겠다면 "트랜잭션 단위"로 자른다.

3. 개발자의 자율성 부여된 곳은 오직 service layer입니다.

Repository Layer

1. 비지니스 로직은 없다.

2. 한 메서드에는 하나의 쿼리만 작성해야한다.

// user.repository.ts
@Injectable()
export class UserRepository {
	constructor(private readonly globalEntityManager: EntityManager) {}

    async insertOne(userInput: IUserInput): Promise<IUser> {
		const user = new User();
        user.name = userInput.name;
        user.phoneNumber = userInput.phoneNumber;

        ...

        return this.globalEntityManager.save(user);
    }

    async findOneByPhoneNumber(phoneNumber: string): Promise<IUser | null> {
    	return this.globalEntityManager
          .createQueryBuilder(User, 'user')
          .where('user.phoneNumber = :phoneNumber', {
            phoneNumber,
          })
          .getOne();
    }
}

간단한 팁은 if문을 금지한다면 대체적으로 비지니스로직이 들어오지않게 됩니다. if문은 오로지 메서드의 인자에서 optional인 값이 있을 경우만 허용됩니다.

// user.interface.ts
export interface IUserSearchConditions {
  type: "student" | "adult";
  ageLTE?: number;
  ageMTE?: number;
}

// user.repository.ts
@Injectable()
export class UserRepository {
	constructor(private readonly globalEntityManager: EntityManager) {}

  	...

    // Set the proper method name on situation !
    async findListBySpecificConditions(conditions: IUserSearchConditions): Promise<IUser[]> {
    	const queryBuilder = this.globalEntityManager
          .createQueryBuilder(User, 'user')
          .where('user.type = :type', {
            userType: conditions.type,
          })

		// "if" allowed only this kind of situation
		if (conditions.ageLTE)
          queryBuilder.andWhere('user.age >= ageMTE', { conditions.ageMTE })

		if (conditions.ageMTE)
          queryBuilder.andWhere('user.age >= ageMTE', { conditions.ageMTE })

		return queryBuilder.getMany();
    }
}

Repository내에서 if문을 이용하지않기때문에 메서드가 많아질 수 있습니다. 하지만 최대한 작은 크기로 메서드를 분리하는 것은 나중을 위해 언제나 옳습니다.

Repository layer를 이용하다보면 service layer 메서드가 단순히 repository 메서드를 호출하는 일밖에 안할때가 많습니다. 간단한 API에서는 당연한 것이니 신경쓰지않으셔도 됩니다. 복잡한 API를 만들 때 repository layer가 빛을 보게 됩니다.

Entity Layer

Constant Layer

// BAD
export enum NATIONALTIY_KO = {
  ALBANIA: '알바니아',
  ARMENIA: '아르메니아',
  AUSTRIA: '오스트리아',
  AZERBAIJAN: '아제르바이잔',
}

// GOOD
export const NATIONALITY_KO = {
  ALBANIA: '알바니아',
  ARMENIA: '아르메니아',
  AUSTRIA: '오스트리아',
  AZERBAIJAN: '아제르바이잔',,
  SAINT_LUCIA: '세인트루시아',
  SAINT_VINCENT_AND_THE_GRENADINES: '세인트빈센트 그레나딘',
  TRINIDAD_AND_TOBAGO: '트리니다드토바고',
  UNITED_STATES: '미국',
} as const;

Interfaces Layer

// user-service.interface.ts
export abstract class IUserRepository {
  findUserByTypeId: (userId: number, type: USER_TYPE_TYPES) => Promise<number>;
  getUserDetail: (userId: number) => Promise<IUser>;
  deleteUser: (userId: number) => Promise<boolean>;
}

// user.service.ts
@Injectable()
export class UserService implements IUserService {
  constructor(
    private readonly userRepository: IUserRepository, // 모두 interface 로 주입됐습니다.
    private readonly loggerService: ILoggerService, // !
    private readonly employeeRepository: IEmployeeRepository, // !
    private readonly companyRepository: ICompanyRepository, // !
  ) {}

  async findUserByTypeId(userId: number) {
  	 ...
  }

  ...
}