Override dispatch to client from local application layer.

[Elijah23Johnson]

Provide an over ride via DI that can dispatch a message to any connected user given a variable key. Say customerId.

Example:

[dsuryd]

This is covered by MulticastVM Send method. If that’s not sufficient, let’s discuss the use case.

[Elijah23Johnson]

True... I see that you have built in the capabilities to send to all subscribed clients who are associated with the MulticastVM instance.

But lets say for instance this library was just a small addition to a highly event driven program.
1.) How do I dispatch events to a given client from an event not associated with dotnetify?
2.) Enterprise Events

Suggestions
1.) We could subscribe to the same VM by referencing the groupname of a MulticastedVM.
2.) Provide another VM class that tracks connection id's and can properly dispatch to that one id would need memory cache for this.

[Elijah23Johnson]

Please note that I have been able to override the dotnetify signalr hub and dispatch to all clients.

[dsuryd]

In such use case, I can see a small component being embedded in the client page that connects to a multicast VM. A plain service with a dispatch method gets injected into the VM and is constructor-initialized so the dispatch method will invoke the VM's Send method. This service can then be injected in other non-VM classes to dispatch events through the multicast VM.

I think this is close to your suggestion 1? This service is plain enough, I don't see it needs to be part of the core library.

[Elijah23Johnson]

True but now when you take it to a multi server architecture or put it behind AWS LB then this solution does not work,

What about an extension in the core library to manage connection and servers that the connection originated from?

With this we can dispatch an action to the connected server and then forward the message to the given client.

Here's a good article about it
https://docs.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-in-signalr

[Elijah23Johnson]

For reference this is a continuation of this conversation ↓
#181
#163
A redis, elastic cluster would work great.

[dsuryd]

Thank you for all your input. I agree there may be a need of an extension to the core library to support multi-server scale-out (as alternative to Azure). But this will be a much more complex and resource-consuming endeavor than I'm willing to take on for a FOSS with no strong sponsorship. I do have a plan to eventually offer this but it will be in a way that can support the long-term viability of the core project (#96). So I'm closing this as out-of-scope.