Open falahati opened 2 years ago
Thanks for support! First we need to determine approach to this feature.
What do you think, would be better and why?
I think adding the forFeature()
is a must with or without this change. forFeature()
allows dependency separation which might be quite useful in a modular sort of way, and as you said it, more in line with what NestJS philosophy dictates or is the norm.
However, this FR is not actually a replacement for the nonglobal modules, but rather helps decrease such needs indirectly by adding a new feature that could in the majority of cases used as a workaround. So from the modular point of view, no this feature is not ideal. However, the added functionalities are not going to be provided with the addition of forFeature
anyway, so one can argue that this feature is completely separate.
But yeah, I suppose forFeature
is more preferable. If we write it the way TypeORM does it we might be able to allow backward compatibility. But I have to double-check. I will take a look into this and keep you in the loop for any finding; might even submit a PR for forFeature
. But in any case, if backward compatibility is broken, you can release a new major version, the migration for users would be easy.
This feature request asks for the possibility of defining more than one exchange or queue and to allow selecting the right queue or exchange using the decorator. This allows for wider advanced usages like for example when a queue is used exclusively by an instance of the service for getting notifications while another is used for load balancing messages or when two exchanges has to be used for a single topic/message. Implementing this feature also greatly decreases the need for non-global feature specific support for the library.
To achieve this and still be compatible with the older version I suggest adding a new
queues
andexchanges
configurable properties with information about one or more exchanges or queues.A
bindingOption
optional argument is then can be added to the decorator allowing it to gets binded to a all or one or more queues or exchanges.channel.consume
obviously has to change to account for this change but it is the only heavy part of this feature.Are you ok with me creating a PR for this?
P.S. Been using this library in production with a dozen microservices happily for the last year, good job, and thank you.