개요 API 에러 응답을 일관된 JSON 포맷으로 통일하고, 비즈니스 예외와 프레임워크 예외를 한 경로로 수집하는 전역 예외 필터 설계와 구현 정리 핵심은 표준 에러 코드 정의, AppError 기반의 명시적 예외 던지기, GlobalExceptionFilter에서의 단일 포맷 출력, ValidationPipe 결과의 구조화, traceId 기반 상관관계 추적 요청 흐름 개요 요청 진입 → ValidationPipe 검증 검증 실패 → 전역 필터에서 표준 응답 변환 검증 통과 → Controller/Service 실행 비즈니스 로직 예외 → AppError 서브클래스 throw → 전역 필터 처리 알 수 없는 예외 → 500으로 표준 응답 변환 최종 응답 포맷은 단일 구조 유지 ...
개요 NestJS에서 @Module은 기능 단위 의존성을 묶는 단위이자 DI 경계를 정의하는 컨테이너 개념임 핵심은 imports로 외부 의존성 수입, providers로 내부 의존성 등록, exports로 외부 공개 대상을 결정하는 흐름 이해가 전부임 Module의 imports, providers, exports @Module 선언의 기본 형태 @Module({ imports: [...], providers: [...], exports: [...] }) class SomeModule {} providers 이 모듈에서 새로 생성해 DI 컨테이너에 등록할 대상 목록 @Injectable 클래스들 중심 Service, Repository, Adapter 등 예시 providers: [BatchService, PortFetcher, StoreService, MergeService] imports 다른 모듈이 exports로 공개한 provider를 이 모듈에서 사용하겠다는 선언 예시 imports: [RepositoryModule, HttpModule, LoggerModule] exports 이 모듈 바깥에서도 사용 가능하도록 내보낼 provider 목록 예시 exports: [JSON_REPOSITORY, LogRepository]정리하면 providers는 내부 생성, imports는 외부 수입, exports는 외부 공개 대상 지정임 ...
개요 NestJS을 다루다 보면 ConfigModule.forRoot(), TypeOrmModule.forRoot() 같은 코드를 보게 됨 보통 “이건 전역 설정이니까 한 번만 하면 끝이고 알아서 싱글톤 유지되겠지?“라고 생각하기 쉬움 하지만 forRoot()를 호출한다고 프레임워크가 알아서 물리적인 싱글톤 인스턴스를 강제하는 건 아님 특히 ScheduleModule처럼 사이드 이펙트(이벤트 리스너, 타이머 등)를 유발하는 모듈을 잘못 다루면, 기능이 중복 실행되는 심각한 버그가 터질 수 있음 이 글에서는 forRoot()의 진짜 의미와 내부 동작, 그리고 ScheduleModule 중복 실행 문제가 왜 생기는지 코드로 뜯어보겠음 forRoot()란 무엇인가 forRoot()는 NestJS의 동적 모듈(Dynamic Module)을 생성하기 위해 관례적으로 쓰는 메서드 이름임 ...
개요 @nestjs/swagger는 NestJS와 Swagger(OpenAPI) 스펙을 연결해 API 문서를 자동 생성하는 모듈임 DTO(Data Transfer Object) 클래스에 메타데이터를 부여해 타입과 예시, 설명 등을 Swagger UI에 노출하는 흐름으로 작동함 핵심 도구는 @ApiProperty와 DTO 유틸리티 타입들(PickType, OmitType, PartialType)임 ApiProperty 개념과 사용 @ApiProperty는 DTO 속성 단위로 문서화 메타데이터를 부여하는 데코레이터임 타입, 설명, 예시, 필수 여부 등을 정의해 Swagger UI에 명확한 스키마 제공 코드와 문서가 한 소스에서 유지되어 일관성 확보에 유리함 간단 사용 예시 class CreateUserDto { @ApiProperty({ description: "사용자 이름", example: "John Doe" }) name: string; }이 속성 정의만으로 Swagger 스키마에 name 필드의 설명과 예시가 노출됨 ...
개요 가드 Guard를 이용해 NestJS 애플리케이션을 위험한 요청으로부터 차단하는 방법 정리 컨트롤러에 도달하기 전 단계에서 인증과 접근 제어 수행하는 패턴 중심으로 설명 가드란 NestJS에서 가드는 애플리케이션에 들어오는 요청을 컨트롤러로 보내기 전에 통과 여부를 결정하는 구성 요소 미들웨어와 유사한 역할이지만 라우트 핸들러 실행 여부를 명시적으로 결정하는 책임에 초점 요청 수명주기에서 미들웨어 다음, 컨트롤러 이전에 실행됨 canActivate가 true 또는 Promise을 반환하면 다음 단계로 진행, false면 기본적으로 403 Forbidden 응답 발생 ...