Separate publisher/consumer connections for rabbitmq

[ttshivers]

According to best practices, it is good to use separate connections entirely for publishers and consumers so RabbitMQ can apply backpressure on the tcp connections if the publisher is sending too many messages but still allow consumers to operate properly and send back acks.

https://www.cloudamqp.com/blog/part1-rabbitmq-best-practice.html#separate-connections-for-publisher-and-consumer

[underfisk]

@ttshivers I like this idea! Is there any action item/follow up that us, the library Authors can do? Updating documentation? Improving the module API?
Feel free to propose and i'd be happy to review/discuss

[ttshivers]

I think this could be accomplished with an internal change where the publish method uses a separate connection that we would also need to set up.

[underfisk]

I think this could be accomplished with an internal change where the publish method uses a separate connection that we would also need to set up.

Do you have a change proposal in mind or something you could show off in a PR? I haven't used the rmq package in awhile so I'm open to suggestions

[ttshivers]

I think this could be accomplished with an internal change where the publish method uses a separate connection that we would also need to set up.

Do you have a change proposal in mind or something you could show off in a PR? I haven't used the rmq package in awhile so I'm open to suggestions

Sure. Also, I think this may involve changing the names of many public properties to properly differentiate between the consumer and producer connections.

nestjs/packages/rabbitmq/src/amqp/connection.ts

Line 147 in 8962eed

get connection(): Connection {

would become consumerConnection and there would also be a publisherConnection.

[underfisk]

I think this could be accomplished with an internal change where the publish method uses a separate connection that we would also need to set up.

Do you have a change proposal in mind or something you could show off in a PR? I haven't used the rmq package in awhile so I'm open to suggestions

Sure. Also, I think this may involve changing the names of many public properties to properly differentiate between the consumer and producer connections.

nestjs/packages/rabbitmq/src/amqp/connection.ts

Line 147 in 8962eed

get connection(): Connection {

would become consumerConnection and there would also be a publisherConnection.

I like that idea! I'm not against a change of API if it's for the better, again this API should evolve and there's room for improvement

[ttshivers]

One thing I'm considering as well is cases where only consumption is used so a publisher channel wouldn't be needed.

Separate connections can be created with the current state by registering the module multiple times so perhaps that might be the way to go.

[underfisk]

A while ago i had the idea of "connection pooling" because it felt that some connections were being recreated and could potentially be re-used but if you do have an RFC feel free to propose, don't feel limited

[irarayjenkins]

Has there been any movement on this?