개요 NestJS는 대규모 서버 애플리케이션을 위한 구조화된 Node.js 프레임워크임 핵심은 Angular 스타일의 아키텍처, 강력한 의존성 주입 컨테이너, 데코레이터 기반 메타프로그래밍 조합 팀 규모가 커질수록 일관성과 유지보수성이 살아나는 타입스크립트 퍼스트 선택지임 구조적 강제의 이점 Nest는 모듈 Module, 컨트롤러 Controller, 서비스 Service 구조를 강제함 계층 분리 패턴 BLL, DAL, 도메인 레이어 등 적용 용이 아키텍처가 일관되게 유지되어 4~10명 규모 팀에서 코드 스타일과 책임 경계가 흐트러지지 않음 Fastify, Express 같은 미니멀 프레임워크 대비 생산성과 일관성 측면에서 팀 단위 효율 우위 ...
개요 NestJS을 다루다 보면 ConfigModule.forRoot(), TypeOrmModule.forRoot() 같은 코드를 보게 됨 보통 “이건 전역 설정이니까 한 번만 하면 끝이고 알아서 싱글톤 유지되겠지?“라고 생각하기 쉬움 하지만 forRoot()를 호출한다고 프레임워크가 알아서 물리적인 싱글톤 인스턴스를 강제하는 건 아님 특히 ScheduleModule처럼 사이드 이펙트(이벤트 리스너, 타이머 등)를 유발하는 모듈을 잘못 다루면, 기능이 중복 실행되는 심각한 버그가 터질 수 있음 이 글에서는 forRoot()의 진짜 의미와 내부 동작, 그리고 ScheduleModule 중복 실행 문제가 왜 생기는지 코드로 뜯어보겠음 forRoot()란 무엇인가 forRoot()는 NestJS의 동적 모듈(Dynamic Module)을 생성하기 위해 관례적으로 쓰는 메서드 이름임 ...
개념/배경 DI(Dependency Injection, 의존성 주입)의 핵심 아이디어는 명확함 객체가 자신이 사용할 의존 객체를 스스로 생성하지 않고, 외부로부터 전달받아 사용하는 것임 이 단순한 설계 변경만으로도 코드의 변경 용이성, 테스트 편의성, 그리고 전체 시스템의 확장성에서 거대한 차이가 발생함 문제 상황: 강한 결합 (Tight Coupling) 전형적인 문제 패턴은 클래스 내부에서 다른 구체적인 클래스(Concrete Class)를 new 키워드로 직접 생성하여 사용하는 것임 의존 대상의 구현이 변경되면, 해당 객체를 사용하는 클래스 내부 코드도 반드시 함께 수정해야 함 단위 테스트(Unit Test)를 작성할 때, 테스트 대상 객체가 의존하는 실제 객체들까지 모두 함께 엮여 들어와 테스트가 복잡하고 무거워짐 예를 들어 Gamer가 BlueSwitchKeyboard를 직접 생성해 사용한다면, Gamer는 BlueSwitchKeyboard라는 구체적인 구현에 영구적으로 고정됨 만약 키보드 종류를 RedSwitchSilentKeyboard로 바꾸려면 Gamer 클래스의 내부 코드를 직접 수정해야 함 이 상태를 결합도가 높다고 부름 ...