Nest.js에서 모듈간의 의존성 관리하기

Nest.js를 사용해서 개발하게 되면 도메인 모델을 기준으로 수많은 모듈이 생기게 된다. 도메인 모델 별로 나누기 때문에 해당 파일이 어떤 역할을 하는지 명시적으로 알 수 있어 매우 편리하지만 서로 다른 모듈끼리 의존성을 관리해줘야 한다.

 

서로 다른 모듈의 의존 관계 설정

아래는 예시 코드이다.

 

// user.module.ts

import { Module } from '@nestjs/common';
import { UserService } from './user.service';

@Module({
  providers: [UserService],
  exports: [UserService],
})
export class UserModule {}


// auth.module.ts

import { Module } from '@nestjs/common';
import { PassportModule } from '@nestjs/passport';
import { JwtModule } from '@nestjs/jwt';
import { AuthService } from './auth.service';
import { LocalStrategy } from './local.strategy';
import { JwtStrategy } from './jwt.strategy';
import { UserModule } from '../user/user.module';

@Module({
  imports: [
    PassportModule,
    JwtModule.register({
      secret: 'secret',
      signOptions: { expiresIn: '60s' },
    }),
    UserModule,
  ],
  providers: [AuthService, LocalStrategy, JwtStrategy],
  exports: [AuthService],
})
export class AuthModule {}

 

먼저 User 도메인에서 사용하는 UserService를 Auth 도메인에서 의존해야 한다고 가정한다. 이 경우에는 Auth 도메인에서 의존할  UserService를 exports 해야 한다. 

 

그리고 AuthModule 에서는 imports에 UserModule을 넣어 의존관계를 만들어 줄 수 있다. 이렇게 작성하게 되면 auth.controller나 auth.service에서 UserService를 주입받아 사용할 수 있게 된다.

 

UserService를 주입하는데 UserModule을 imports 하는 이유

먼저 첫 번째 이유는 Nest.js의 기본적인 동작 방식에 있다. Nest.js는 provider를 설정하게 되면 기본적으로 싱글톤 패턴으로 동작하기 때문에 만약 UserService를 AuthModule의 provider에 직접 넣게 된다면 싱글톤 패턴을 어기게 된다.

 

두 번째 이유는 첫 번째 이유와 밀접하게 관련이 있는데 메모리 사용량의 문제이다. 같은 기능을 하는 객체를 모듈별로 생성하게 된다면 메모리 사용량도 증가하게 된다. 

 

세 번째 이유는 provider의 생명주기에 대한 문제이다. 여러 개의 객체가 생성되게 된다면 각각의 모듈에서 생성된 객체가 달라질 수 있기 때문에 생명주기를 관리해줘야 하는 경우가 생기게 된다.

 

 

모듈 간의 의존성 관리를 할 때 주의해야 하는 것

도메인 모듈 간의 의존성을 관리하다 보면 이상하게 순환참조가 필요한 경우가 생긴다. 이렇게 모듈 간의 순환참조가 나타나는 건 코드의 복잡도를 높이고, 의존성 관리에 어려움이 생기게 되기 때문에 지양해야 한다.

 

만에 하나 Nest.js 환경에서 순환참조를 해야 하는 상황이 온다면 forwardRef()를 사용해서 순환참조 문제를 회피할 수 있지만, 가장 좋은 방법은 설계적인 부분에서 해결하는 것이다. 

 

그에 대한 글은 다음글에 작성할 예정이다.