Is it required to define the exchange and pseudo queue for direct reply-to?

[L-U-C-K-Y]

Hi all

Thanks for this great library, we just learned about it as we run into limitations of the @nestjs/microservices lib.

While reading the docs, I saw that the direct reply-to feature is used and I was wonder why a queue is defined in the below example:

import { RabbitRPC } from '@golevelup/nestjs-rabbitmq';
import { Injectable } from '@nestjs/common';

@Injectable()
export class MessagingService {
  @RabbitRPC({
    exchange: 'exchange1',
    routingKey: 'rpc-route',
    queue: 'rpc-queue',
  })
  public async rpcHandler(msg: {}) {
    return {
      response: 42,
    };
  }
}

According to the rabbitmq docs:

The direct reply-to feature allows RPC clients to receive replies directly from their RPC server, without going through a reply queue.

Consume from the pseudo-queue amq.rabbitmq.reply-to in no-ack mode. There is no need to declare this "queue" first, although the client can do so if it wants.
Set the reply-to property in their request message to amq.rabbitmq.reply-to.

The RPC server will then see a reply-to property with a generated name. It should publish to the default exchange ("") with the routing key set to this value (i.e. just as if it were sending to a reply queue as usual). The message will then be sent straight to the client consumer.

As I understand it from the docs, no queue is required and the default exchange can be used.
If a queue is required, I assume it should be fine if all requests use the same queue? Would there be any filtering overhead if all clients listen to the same queue?

Many thanks!!

[WonderPanda]

The queue you're referring to is for the client issuing the request (for the response to be returned to), not the destination for the request.

Without the automatic use of the reply-to queue, if you wanted to get a response back from the rpc-route in the example above you would have to set up a queue on which the response would be sent back so that you could consume it.

Because the library abstracts the reply-to queue, you can simply make a request to an RPC route using a promise with async/await and you'll get the response back automatically over the reply-to queue without doing any extra work

[L-U-C-K-Y]

Hey @WonderPanda

Many thanks for you reply!

Sorry, I am struggling a bit to understand your answer.

The queue you're referring to is for the client issuing the request (for the response to be returned to), not the destination for the request.

Are you referring to the queue: 'rpc-queue', line? This means that an RPC request is returned to the rpc-queue queue.

From the RabbitMQ docs, I had the impression that a request is returned to the reply-to queue?

To use direct reply-to, an RPC client should:

Consume from the pseudo-queue amq.rabbitmq.reply-to in no-ack mode. There is no need to declare this "queue" first, although the client can do so if it wants.

If multiple clients would like to make a request to the same RPC handler, would I need to create multiple handlers with multiple reply-to queues? Or do those need to listen to all the same rpc-queue queue?

Thank you!

[WonderPanda]

No, rpc-queue is where the RPC will be listening. It attaches to the exchange and routing key and all of the messages sent will end up in its own queue to be processed. If you want to get a response you need to send a request to to the exchange + routing key where the RPC is listening.

Once the RPC queue receives and processes the message the question is, how does it send you back a reply? Normally you would have to set up your own queue manually to receive the response on. With direct-reply you don't need to worry about that.

The takeaway is that the library abstracts this away from you and there is very little you need to do. Assuming you have an RPC listener configured as above and you want to get a response from it, you just do this:

const response = await amqpConnection.request<ExpectedReturnType>({
  exchange: 'exchange1',
  routingKey: 'rpc',
  payload: {
    request: 'val',
  },
  timeout: 10000, // optional timeout for how long the request
  // should wait before failing if no response is received
});

There is nothing else you need to do as a requester, all of the direct reply to mechanism is abstracted away for you.

Additional Info

You're not required to give your RPC listener a dedicated queue, but it can be useful depending on your architecture. If you don't, a random one will be auto assigned to it. If your application restarts though there are chances that messages that haven't been processed yet could be lost.

[L-U-C-K-Y]

Thanks a lot, all clear!

[WonderPanda]

No worries, glad it helped

[L-U-C-K-Y]

Sorry if it is the wrong place, does this lib support topic exchanges with * and # wildcards?

[WonderPanda]

Yes it does. I'd recommend spinning up a playground with RabbitMQ and NestJS CLI and playing around with it so you can see for yourself what is supported