nestjs

nestjs copied to clipboard

Hi, I have a simple setup where I'm creating 2 nest factories as:

const services = [
  {
    name: 'addresses',
    createModule: StockModule,
    environment: {
      port: 3001
    }
  },
  {
    name: 'addresses1',
    createModule: AppModule,
    environment: {
      port: 3002
    }
  }
].forEach((service: any) => {
  (async function () {
    const app = await NestFactory.create(service.createModule);
    app.listen(service.environment.port);
  })();
});

In the StockModule I'm publishing a msg and in AppModule I have the pubSub.

At startup the consumer is not created.

If use a different setup as:

 @Module({
   imports: [
     StockModule,
     AppModule,
   ]
 })
 export class DevModule { }

 async function bootstrap() {
   const app = await NestFactory.create(DevModule);
   app.listen(3000);
 }

 bootstrap();

All works as expected and I can see the consumer:

[Nest] 408353  LOG [RabbitMQModule] StockService.pubSubHandler {subscribe} -> BLOCK.TRANSACTION::*.block::stock-queue

The 2 factories setup is useful for keeping factories independent based on port for testing. Is there anything that I'm missing?

Thank you

Investigating why it's not registering the consumers I've noticed that the module bootstrap is done only once:

  public async onApplicationBootstrap() {
    if (RabbitMQModule.bootstrapped) {
      return;
    }

    RabbitMQModule.bootstrapped = true;
---------
  }

The boostrapped is set to true and not registering the consumer on the second module.

This looks like it was set like this on purpose, I just wonder what was the reasoning ?...

@tomandrei Thanks for sharing a piece of your setup. It's a bit weird and uncommon to see what you're trying to do, ideally, you would only register the module once and dynamically bind providers (and you can have different rules within the module) but I've never seen where you start 2 applications at once there. Although i can see a potential fix of having a unique token per RabbitMQModule to differentiate the bootstrap OR potentially try to support your use case by (possibly) allowing to bypass this check. This would require an investigation but at this moment i don't have too much bandwidth to do so. If you're able to contribute and propose a change (with test coverage) in order to support this, feel free to and I'll be happy to review