#Bootstrap a microservice using ConfigurationService

38 messages · Page 1 of 1 (latest)

manic drift
#

Hi there, as the title implies I'm trying to do this:

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    MyModule,
    {
      transport: Transport.TCP,
      options: {
        port: 54321, // <== How can I take this value from the ConfigurationService ?
      },
    },
  );

  await app.listen();
}
bootstrap();

What's the recommended solution for this use case ? Thanks!

compact mulch
manic drift
compact mulch
#

No clue. Kamil hasn't seemed keen on the idea in the past

manic drift
compact mulch
#

That's one way, yeah

manic drift
#

While here I'm facing another weird issue related to the configuration service.

Basically this works 👇

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true, // <== 1. Set this global
      envFilePath: ['.devcontainer/.env', 'apps/collections/.env'],
      load: [MICROSERVICE_CONFIG, MONGO_CONFIG, INTERVALS_CONFIG],
    }),
    MongooseModule.forRootAsync({
      useFactory: (mongoConfig: ConfigType<typeof MONGO_CONFIG>) => ({ // <== 3. Able to inject the dependency here.
        auth: {
          username: mongoConfig.username,
          password: mongoConfig.password,
        },
        uri: `mongodb://mongo`,
        dbName: mongoConfig.dbName,
      }),
      inject: [MONGO_CONFIG.KEY], // <== 2. Able to resolve the token here.
    }),
  ],
  controllers: [CollectionsController],
})
export class CollectionsModule {}

But this does not 👇

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: false, // <== 1. NOT global
      envFilePath: ['.devcontainer/.env', 'apps/collections/.env'],
      load: [MICROSERVICE_CONFIG, MONGO_CONFIG, INTERVALS_CONFIG],
    }),
    MongooseModule.forRootAsync({
      imports: [ConfigModule], // <== 2. Import the ConfigModule for DI.
      useFactory: (mongoConfig: ConfigType<typeof MONGO_CONFIG>) => ({ // <== 3. Fails to resolve DI.
        auth: {
          username: mongoConfig.username,
          password: mongoConfig.password,
        },
        uri: `mongodb://mongo`,
        dbName: mongoConfig.dbName,
      }),
      inject: [MONGO_CONFIG.KEY], // <== 3. Fails
    }),
  ],
  controllers: [CollectionsController],
})
export class CollectionsModule {}

Any idea why ?

compact mulch
#

That's odd. But I find @nestjs/config to be more complex than necessary, to be honest. I would guess that the ConfigModule is resolving early, because it exists, but doesn't yet (for whatever reason) expose the the MONGO_CONFIG (maybe it hasn't loaded yet? I dunno) when you're doing it in a non-global manner. I can try to look into the code a bit, especially if you can get me a rperoduction

manic drift
compact mulch
#

If you do open an issue, make sure it's in @nestjs/config and make sure to provide a repository with it

#

If it's trivial, that means it'll be easy to set up 🙂

manic drift
compact mulch
#

Okay, so I have already found a solution that might interest you. In the imports of the MongooseModule you can do ConfigModule.forFeature(MONGO_CONFIG.KEY) and get the configuration imported propery that way

#

I think overall what's happening is making sense, as I think more about this

#

When we have imports: [ConfigModule.forRoot(options)] in the WithConfigTypeModule, we are saying to provide the MONGO_CONFIG.KEY provider to the providers and controllers that belong to the WithConfigTypeModule. The MongooseModule is essentially its own sub-module that WithConfigTypeModule needs to import, so it can't "reach up" into the WithConfigTypeModule to get the MONGO_CONFIG.KEY provider, as the MongooseModule needs to finish setting up its providers before WithConfigTypeModule can start setting up the providers it has.

Does that make sense?

manic drift
compact mulch
#

who does importing the configserivce work?
Do you mena when/where does importing the configservice work

manic drift
#

I understand that the mongoose module is its own submodule but still in the factory method I do import the config module.

compact mulch
#

You import the ConfigModule, but that ConfigModule doesn't necessarily expose the MONGO_CONFIG.KEY provider

#

Like I said, Nsts@nestjs/config is not super intuitive

manic drift
#

I thought it was kind of similar to exporting the ConfigModule

#

When re-exporting the module I don't need to say exports: [MyModule.forRoot(option)] isn't it ? I can simply exports: [MyModule].

compact mulch
#

Just importing ConfigModule in the MongooseModule's imports doesn't add the MONGO_CONFIG.KEY to the exports of the ConfigModule. You'd need to add the load property to the one in MongooseModule's improts or use the forFeature()

compact mulch
manic drift
compact mulch
#

Module re-exporting is where a module imports a dynamic module with its configuration, and later re-exports the dynamic module

#

This is two modules both importing the same dynamic module with "separate" configurations

manic drift
#

Alright alright I understand better

#

Is there a way to load several config using the "forFeature" method ?

compact mulch
#

I think you'd just need multiple ConfigModule.forFeature() calls, but I can look back at the signature

manic drift
#

Like if my factory needed 3 ConfigType how would I do that ?

compact mulch
#

Yeah just multiple forFeature() calls

manic drift
#

Thanks a lot for your help!

#

Should I close the issue ?

compact mulch
#

I think so