feat(rabbitmq): add a new property handlers to RabbitMQModule config

[lucas-silveira]

It was added a new property called handlers to RabbitMQModule config in order to be able to use
dynamic values in handler configs.

Example RabbitMQModule config:

RabbitMQModule.forRootAsync(RabbitMQModule, {
      useFactory: (config: ConfigService) => ({
        exchanges: [
          {
            name: config.get('rabbitMq.exchanges.topic'),
            type: 'topic',
          },
        ],
        // new property
        handlers: {
          handler1: {
            exchange: config.get('rabbitMq.exchanges.topic'),
            routingKey: 'test.*',
            queue: config.get('rabbitMq.queues.payments.name'),
            queueOptions: config.get('rabbitMq.queues.payments.options'),
          },
        },
        uri: config.get('rabbitMq.host'),
      }),
      inject: [ConfigService],
    }),

Example Subscription decorator:

@RabbitSubscribe({
    name: 'handler1',
  })
  public async testHandle(data: any): Promise<void> {
    // do something...
  }

Fix issue #445

[danocmx]

Would it not make more sense to have handlers be an object rather than array?

[lucas-silveira]

Would it not make more sense to have handlers be an object rather than array?

Hello @danocmx
Thanks for the comment.
I don't have a strong opinion on this. Why do you think an object makes more sense?

[danocmx]

I assume the handler name should be unique, which would be easier to manage in an object as property name.

[lucas-silveira]

I assume the handler name should be unique, which would be easier to manage in an object as property name.

You right! I hadn't thought of that. It's simpler to solve this with objects. I will do the change.

[WonderPanda]

I personally think it would be better to just force your config resolution to happen before decorators are resolved. Managing your App Configuration through the framework DI system is an antipattern in my opinion but I also realize that most people who build Nest apps are just used to doing things this way so its not worth fighting against the conventions at this point.

With that in mind I'm open to adding this new API but want to make sure there's some e2e test coverage added before we can merge

[lucas-silveira]

@WonderPanda
I'm not sure I agree with your point. I particularly find it very advantageous to use the DI and configService mechanism to manage the configs, as this allows me to centralize the application's configuration, add static values (which don't make sense to stay in the environment variables) and perform empty field validations. But it is a very debatable point.
Thanks for the comment. I will add the e2e tests.

[WonderPanda]

@WonderPanda I'm not sure I agree with your point. I particularly find it very advantageous to use the DI and configService mechanism to manage the configs, as this allows me to centralize the application's configuration, add static values (which don't make sense to stay in the environment variables) and perform empty field validations. But it is a very debatable point. Thanks for the comment. I will add the e2e tests.

All of your points can be achieved pretty easily by parsing configuration prior to bootstrapping the Nest application and outside of the DI system which provides the added benefit of allowing you to use config values directly inside of your decorator function calls.

However, since it seems like most Nest apps use the Nest config service it's probably worth it to provide the workaround that you've implemented here

[thiagoanselmo]

It was added a new property called handlers to RabbitMQModule config in order to be able to use dynamic values in handler configs.

Example RabbitMQModule config:

RabbitMQModule.forRootAsync(RabbitMQModule, {
      useFactory: (config: ConfigService) => ({
        exchanges: [
          {
            name: config.get('rabbitMq.exchanges.topic'),
            type: 'topic',
          },
        ],
        // new property
        handlers: {
          handler1: {
            exchange: config.get('rabbitMq.exchanges.topic'),
            routingKey: 'test.*',
            queue: config.get('rabbitMq.queues.payments.name'),
            queueOptions: config.get('rabbitMq.queues.payments.options'),
          },
        },
        uri: config.get('rabbitMq.host'),
      }),
      inject: [ConfigService],
    }),

Example Subscription decorator:

@RabbitSubscribe({
    name: 'handler1',
  })
  public async testHandle(data: any): Promise<void> {
    // do something...
  }

Fix issue #445

Publish this feature, I'm looking forward to using it ; )

[WonderPanda]

@thiagoanselmo Published as @golevelup/[email protected]

[thiagoanselmo]

@WonderPanda

I have the latest version of the 3.2.0 package, but it's still not working.

It gives the console it took as handler settings, it doesn't initialize the consumer..

When I check the RabbitMQ GUI there is no active consumer.

[chromey]

@thiagoanselmo my fix for #489 made it into 3.3.0 that was released recently. Let me know if it works for you.

[thiagoanselmo]

@chromey Yes, working for me the version 3.4.0

Thanks!!