Using RoutingKey and QueueName as a combination to receive messages

[BhupenPal]

Hi, I am trying to implement a Fire and Forget system where the routing is done on the basis of the combination of RoutingKey and QueueName.
But it looks like the handlers only receive the message from the queue irrespective of the routingKey.
I get that the routingKey in the decorator is used to manage the queue binding. But is there anyway to do what I am trying to do?

[WonderPanda]

How are you attempting to publish the fire and forget messages? Please share some code that further demonstrates what you're trying to accomplish

[BhupenPal]

This is the service from which I am firing the events:

export class AppService {
  constructor(private readonly queueService: QueueService) {}

  createProduct() {
    // CREATION LOGIC
    const productId = (Math.random() * 10000).toFixed(0);
    const productName = 'SUPER_CAR';

    // FAF - ProductCreated
    const message = {
      productId,
      productName,
    };

     this.queueService.publish({
       message,
       messageMeta: {
         messageId: productId.toString(),
         routingKey: 'product-created',
       },
     });

    // RESPONSE
    return {
      message: 'Product creation successful',
      ...message,
    };
  }
}

And this is the controller on which I am trying to listen to the events:

@Controller()
export class AppConsumer {
  @RabbitConsumer({
    routingKey: 'product-created',
    queue: 'notifications-slack',
  })
  public async sendProductCreatedNotificationOnSlack(msg) {
    console.log('Sending msg to slack', msg);
  }

  @RabbitConsumer({
    routingKey: 'product-purchased',
    queue: 'notifications-slack',
  })
  public async sendProductPurchasedNotificationOnSlack(msg) {
    console.log('Sending msg to slack', msg);
  }
}

[WonderPanda]

This setup looks a bit strange to me. You're not specifying anything about the queue when you're publishing messages (which I think is good). But you shouldn't use the same queue to bind to multiple routing keys with different handlers or you're going to get weird behavior.

You should have a dedicated queue per handler or you're going to need to unpack the message inside the handler yourself and do conditional logic based on where it came from

[BhupenPal]

@RabbitConsumer is wrapper around @RabbitSubscribe and it just sets the default value of exchange so that I do not have to write it every time.

Also, I am going with this approach because I can at any given time add another consumer without changing the existing code:

  @RabbitConsumer({
    routingKey: 'product-created',
    queue: 'notifications-whatsapp',
  })
  public async sendProductCreatedNotificationOnWhatsapp(msg) {
    console.log('Sending msg to whatsapp', msg);
  }

[BhupenPal]

This setup looks a bit strange to me. You're not specifying anything about the queue when you're publishing messages (which I think is good). But you shouldn't use the same queue to bind to multiple routing keys with different handlers or you're going to get weird behavior.

You should have a dedicated queue per handler or you're going to need to unpack the message inside the handler yourself and do conditional logic based on where it came from

But wouldn't it be great to have Routing Logic for RabbitMq messages so that we do not have to add that conditional logic inside our handlers. Exactly like Nestjs routes the Http requests to the correct handler.

[WonderPanda]

It would be nice, but its just not how RabbitMQ works. Its a separate protocol from HTTP with its own characteristics