kamilmysliwiec
commented
4 years ago A microservice Server does not have access to system services organically, a service, if required must be assigned manually. In other words, there is no dependency injection support for the Server implementation and one must set value to the server instance directly.
This is how it was designed and honestly, I don't see any reason why we should consider rewriting this (all the existing strategies live and should live outside of the container).
Some implementation might require more logic and work, for example, a strict bus like the Azure Service Bus will require pre-defined queues/topics so a verification might be required.
You should expose them as a public API of your strategy then (options object). Unfortunately, passing precalculated/resolved values (from the container) isn't possible yet, but we're tracking this here https://github.com/nestjs/nest/issues/2343
lock[bot]
Feature Request
Is your feature request related to a problem? Please describe.
A microservice
Serverdoes not have access to system services organically, a service, if required must be assigned manually.In other words, there is no dependency injection support for the
Serverimplementation and one must set value to the server instance directly.Describe the solution you'd like
Allow setting a class to the
strategyproperty and when a class is set instantiate it using the container.Since the
NestMicroserviceclass is also an application context this shouldn't be an issue.What is the motivation / use case for changing the behavior?
Some implementation might require more logic and work, for example, a strict bus like the Azure Service Bus will require pre-defined queues/topics so a verification might be required. Or, an option to create them on the fly.