-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Support for Asynchronous Configuration in CqrsModule #1912
Comments
Unable to provide RabbitMQEventPublisher asynchronously in the CqrsModule I have created a custom RabbitMQEventPublisher for event publishing in my NestJS application, and I need to provide it asynchronously so that I can inject AmqpConnection from the @golevelup/nestjs-rabbitmq package. I am using a wrapper module to configure the RabbitMQEventPublisher as the event publisher for CqrsModule. However, I am encountering issues with this approach. Current Code Setup:
|
Sounds good. Would you like to create a PR for this? You could use this module as a reference https://github.com/nestjs/axios/blob/master/lib/http.module.ts |
Thank you for the suggestion! I’ll go ahead and create a PR. I’ll refer to the module you mentioned for structure and implementation. I’ll make sure to follow the existing patterns and conventions used in the codebase. Let me know if there’s anything else you’d like me to consider. |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Currently, the CqrsModule only provides a forRoot method for configuration, which requires static options at the time of module initialization. However, in many applications, configuration values (such as feature flags, database connections, or external API calls) need to be resolved asynchronously, making it difficult to dynamically configure the CQRS module.
Describe the solution you'd like
Proposed Solution:
Introduce a forRootAsync method in CqrsModule, allowing asynchronous configuration using useFactory, useClass, or useExisting. This would enable dependency injection and support dynamic configurations.
Suggested API:
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
Benefits:
This feature would be especially useful for applications utilizing microservices, distributed event handling, or feature flag-based CQRS logic.
The text was updated successfully, but these errors were encountered: