NestJS 개요

NestJS는 타입스크립트로 백엔드 서버를 만들 때 사용하는 프레임워크입니다.

NestJS를 사용하는 이유

구조 문제 해결

Node.js로 백엔드 서버를 만들 때 가장 많이 사용되는 Express는 구조를 자유롭게 작성할 수 있습니다.

개발자마다 파일/폴더 구성이 제각각이라 동일한 프로젝트 안에서도 코드 파악이 어려운 문제가 발생합니다.

또한 새로운 개발자가 투입되거나 개발자가 다른 프로젝트에 투입될 때 구조를 파악하는데 시간이 필요합니다.

NestJS는 구조를 강제해 문제를 해결합니다.

객체 관리 위임

객체 관리를 프레임워크에서 해주기 때문에 객체의 생성, 초기화, 소멸을 신경쓰지 않아도 됩니다.

또한 프레임워크에서 관리하는 객체는 사용하기 쉽습니다.

라이브러리 의존성 해결

npm에는 검증되지 않은 라이브러리, 유지보수가 중단된 라이브러리들이 많습니다.
NestJS는 검증된 라이브러리, 자체 제작 라이브러리를 사용하기 때문에 의존성 문제에서 상대적으로 자유롭습니다.

객체 관리 위임

NestJS는 근본적으로 객체 관리를 위한 프레임워크입니다.

NestJS의 객체 관리 기능을 이용하면 다른 객체를 사용할 때 필요한 작업이 줄어듭니다.

객체 관리를 직접 할 때

객체 관리를 직접 하면 객체를 사용할 때 추가적인 작업이 필요합니다.

객체를 사용하는 곳

export class main {
  const cpu = new AmdCpu();
  const ram = new HynixRam();
  const ssd = new SamsungSsd();
  const computer = new Computer(cpu, ram, ssd);

  run() {
    computer.run();
  }
}

사용하고 싶은 객체

export class Computer {
  constructor(
    private cpu: AmdCpu,
    private ram: HynixRam,
    private ssd: SamsungSsd
  ) {}

  run() {
    console.log('실행');
  }
}

객체 관리를 위임하면

NestJS에 객체 관리를 위임하면 필요한 객체만 명시하면 사용 가능합니다.

객체를 사용하는 곳

export class main {
  constructor(private computerService: ComputerService) {}

  run() {
    computer.run();
  }
}

사용하고 싶은 객체

@Injectable()
export class Computer {
  constructor(
    private cpu: AmdCpu,
    private ram: HynixRam,
    private ssd: SamsungSsd
  ) {}

  run() {
    console.log('실행');
  }
}

객체 관리 위임의 장점

코드 작성양 감소

실제 앱 개발시에 하나의 객체가 여러 객체를 사용하는 일이 많습니다.

객체 관리를 위임하면 객체를 사용할 때 추가 작업이 필요 없기 때문에 코드의 작성양이 줄어듭니다.

코드 작성양이 줄어드는 것은 아래 이유로 항상 중요합니다.

1. 실수 감소
2. 코드 변경 시 필요한 작업 감소(유지보수성 증가)

테스트 용이성

NestJS에 관리를 위임한 객체는 애플리케이션 전체에서 하나만 생성됩니다.

이것은 하나의 객체가 정상적으로 작동하면 다른 곳에서도 정상적으로 작동하는 것을 의미합니다.

따라서 여러 곳에서 테스트 할 필요성이 줄어듭니다.(그래도 안 하면 안 됨)

NestJS 프로젝트 구조

• node_modules: 라이브러리들이 저장된 폴더
• src: 실제 코드를 작성하는 폴더
  • main.ts: 최상위 모듈인 AppModule을 실행시키는 파일
  • app.controller.spec.ts: AppModule의 단위 테스트를 위한 파일
  • app.controller.ts: AppModule의 라우팅을 담당하는 파일
  • app.module.ts: AppModule의 구성 요소를 명시하는 파일
  • app.service.ts: AppModule의 비즈니스 로직이 들어있는 파일
• test: E2E(End to End) 테스트 파일들이 있는 폴더
• .gitignore: git 연동 시 무시하는 파일 및 폴더 규칙을 관리하는 파일
• .prettierrc: 코드를 정리해주는 prettier라는 라이브러리의 설정 파일
• eslint.config.mjs: 자바스크립트/타입스크립트 문법을 체크하는 ESLint라는 라이브러리의 설정 파일
• nest-cli.json: NestJS 프로젝트의 구성을 관리하는 파일
• package-lock.json: 프로젝트에서 사용하는 라이브러리들의 정확한 버전과 의존성을 관리하는 파일
• package.json: 프로젝트에서 사용하는 라이브러리들과 명령어를 관리하는 파일
• README.md: 프로젝트의 정보를 설명하는 파일
• tsconfig.build.json: 프로젝트 배포를 위한 빌드 시 제외해야 하는 폴더와 파일들을 관리하는 파일
• tsconfig.json: 프로젝트에서 타입스크립트 사용 시 어떤 규칙을 사용할 것인지 설정하는 파일

NestJS 요청 처리 과정

각각의 구성 요소가 하는 일

• Middleware : 미들웨어는 보통 3자 라이브러리를 의미합니다. 다른 스키매틱이 하는 일을 할 수도 있고, 이외의 일을 할 수도 있습니다.
• Guard : 인증과 권한 관리. 클라이언트의 요청이 라우팅을 활성화 할 수 있는지 여부를 결정합니다.
• Interceptor : 요청 혹은 응답에서 필요한 로직을 추가합니다.
• Pipe : 데이터 유효성 검증 및 데이터 변환
• Controller : 라우팅
• Service : 실제 요청을 처리하는 부분
• Exception filter : 요청 처리 중 발생하는 오류에 대한 예외 처리

간략 버전

상세 버전

1. 사용자 요청
2. 미들웨어
3. 가드
4. (요청 전)인터셉터
5. 파이프
6. 컨트롤러
7. 서비스
8. (요청 후)인터셉터
9. 예외 필터
10. 응답

파일 명명 규칙

모듈명.스키매티명.ts

모두 소문자를 사용합니다.

둘 이상의 단어는 -로 연결합니다.

app.module.ts
app.controller.ts
my-app.service.ts

프로젝트 시작 시 추가해야 하는 패키지 목록

# 데이터 검증 및 변환
npm i class-validator class-transformer 

# 환경구성
npm i @nestjs/config joi

# ORM
npm i @nestjs/typeorm typeorm # TypeORM
npm i typeorm-naming-strategies # 카멜케이스와 스네이크 케이스 매핑
npm i @mikro-orm/core @mikro-orm/nestjs # MikroORM
npm i prisma @prisma/client # Prisma

# DB 클라이언트
npm i pg
npm i mysql # 혹은 mysql2
npm i mssql
npm i oracledb

# Mapped Type 사용을 위해 아래 중 하나
npm i @nestjs/mapped-types
npm i @nestjs/swagger
npm i @nestjs/graphql

# 인증, 인가
npm i bcrypt @nestjs/jwt @nestjs/passport passport passport-jwt
# 타입스크립트 관련 라이브러리들은 개발 시에만 필요. --save-dev 해도 문제 없긴 함
npm i --save-dev @types/bcrypt @types/passport-jwt @types/passport @types/jsonwebtoken