Add message handling extension based on the Azure Functions builder type
Closed this issue · 5 comments
Is your feature request related to a problem? Please describe.
We have already a set of extensions to add message handlers to the IServiceCollection but not for the IFunctionsHostBuilder which is available for Azure Functions projects.
Describe the solution you'd like
Add the whole set of extensions for this Azure Functions type so to make it more discoverable.
Additional context
Came across during review of #141
If we want support multiple routers for multiple Azure Functions endpoints in the same project, we need a way to register the message handlers separately for each router (which #152 will handle for us) but in case of the Azure Functions, we don't have a message pump which to which the router will be set but we have to retrieve it by injecting it into our Azure Function.
So, we need an extra abstraction to retrieve a kind of router. This would mean that we can register our routers with a name or something, and that we can retrieve it afterwards depending on which Azure Function you're in.
Do we really need (yet-another) abstraction? Isn't that something we can manage during the registration of everything? Worst case in dedicated extensions for Azure Functions?
Do we really need (yet-another) abstraction? Isn't that something we can manage during the registration of everything? Worst case in dedicated extensions for Azure Functions?
Well, we need some kind of relationship between the function and the router. We could make the routers 'unique' by giving them a name (as proposed), we can maybe come up with a way to link the router to a type(s) so it knows which router to inject in the function, or we create (just like for the Service Bus) a dedicated router that behind the scenes delegates, or maybe we create a router with a message type generic (or generics if supports multiple) the DI system knows which one to inject...
Let's work on a proposal from a user-experience side and evaluate the approach, WDYT?
This is implicitly by introducing a dedicated type when adding a message pump. #172