RabbitMQ: dynamic subscription, queue and decorator values #323
-
I'm trying to make the topic of a subscription configurable [via NestJs Module-Initialization]. The problem is, decorators cannot use values available at Object creation time. Is there a way to create a Subscription 'manually' and keep the benefits of the Decorator-variant (automatic reconnect, ...)? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
This is a major shortcoming of the NestJS configuration system and why I strongly suggest that configuration should occur separate from DI/Module initialization. The config package The other option is to manually call If you want to stick with your existing config system you can definitely manually set up subscriptions/rpc in module init. Just inject the AmqpConnection and call the methods directly |
Beta Was this translation helpful? Give feedback.
-
Hi guys, I know this is a old discussion but I recently started to research this pack and as usual am I were reading some common issues/doubts, etc before to start to working with it and found this post. Why just don't initialize the ConfigService class outside of the // configuration.ts
export const configuration = () => ({
NODE_ENV: process.env.NODE_ENV,
RABBITMQ: {
HTTP: {
HOST: process.env.RABBITMQ_HTTP_HOST,
PORT: process.env.RABBITMQ_HTTP_PORT,
VHOST: process.env.RABBITMQ_HTTP_VHOST,
USER: process.env.RABBITMQ_HTTP_USER,
PASS: process.env.RABBITMQ_HTTP_PASS,
},
ROUTINGKEYS: {
test: 'test',
},
EXCHANGES: {
test: 'test',
},
QUEUES: {
vendor: {
test: 'vendor-test',
},
},
},
});
// controller.ts
const configService = new ConfigService(configuration);
@Controller()
export class BulksmsonlineController {
@RabbitSubscribe({
queue: configService.get('RABBITMQ.QUEUES.vendor.test'),
exchange: configService.get('RABBITMQ.EXCHANGES.test'),
routingKey: configService.get('RABBITMQ.ROUTING.test'),
queueOptions: {
durable: true,
},
}) There is some drawback use it on this way? |
Beta Was this translation helpful? Give feedback.
-
here my solution for these cases. Currently i use nestjs's built-in config module but i couldn't use it while declaring queue listener and i solved the problem by creating another class. Simply import it and use anywhere you want. I know it is simple and easy but wanted to share it in case somebody thinks solution for the problem :) import * as dotenv from 'dotenv';
dotenv.config({
path: '.env',
});
class Queues {
public readonly listening: {
QUEUE_NAME: string;
};
public readonly remote: { QUEUE_NAME: string };
constructor() {
this.remote = {
QUEUE_NAME: this.prepare('queue_name'),
};
this.listening = {
QUEUE_NAME: this.prepare('queue_name'),
};
}
private prepare(queueName: string) {
const mqType = process.env.MQ_TYPE;
if (mqType === 'development') {
return `${queueName}_${mqType}`;
}
return queueName;
}
}
export const QUEUES = new Queues();
|
Beta Was this translation helpful? Give feedback.
This is a major shortcoming of the NestJS configuration system and why I strongly suggest that configuration should occur separate from DI/Module initialization. The config package
@golevelup/profiguration
which I use for my own projects specifically gets bootstrapped at the start of your application before any imports are evaluated so you can actually use it to configure decorators.The other option is to manually call
dotenv.config
at the top of your main entry point file at which point you should be able to reference process.env variables in your decoratorsIf you want to stick with your existing config system you can definitely manually set up subscriptions/rpc in module init. Just in…