Notifications with Signalr

Question

I want to create a notification system in my web app (MVC) using Signalr 2.

When someone in the app does a certain action some users (not all and not always the same) should be notified. Something like what we have here in the O.R., when someone interacts with a question. My question is this::

What would be a better strategy to send the message to customers?

Should I store the connectionId in a bank and then return this value to whom it should be notified? This way the database would return the list of connectionId users who must be notified after the action.

I’m new at this and I don’t know how to adapt to my business.

Answer 1

An interesting way to send a notification to specific users is by using groups. For each type of notification, you create groups for each item and connect necessary customers to these groups. A simple example:

public class MeuHub : Hub
{
    public Task EntraNoGrupo(string grupoId)
    {
        return Groups.Add(Context.ConnectionId, grupoId);
    }

    public Task SaiDoGrupo(string grupoId)
    {
        return Groups.Remove(Context.ConnectionId, grupoId);
    }

    public void NotificaGrupo(string grupoId, string mensagem)
    {
        Clients.Group(grupoId).algumMetodoNosClientes(mensagem);
    }

} 

To connect a client to a group, simply invoke the method EntraNoGrupo of your customer, passing the Id of that group:

hubProxy.invoke('EntraNoGrupo', '453841'); // o Id do grupo

That is, the method EntraNoGrupo is just a way for the customer to get into a group, and this method should be called on all customers in that group.

For more details, read on documentation on Signalr Groups.

---

Now, about linking a connectionId to a user, there are some ways you can do this, one of them you even mentioned. To decide which is best for your scenario, see the following table:

It’s in English but I think you can understand.

Single-user Groups

For your particular scenario, the option Single-user Groups is no longer possible as it suggests that you create a group for each user, however this removes the possibility for you to notify different customers in the same group.

In Remembrance

This is more for trivial notifications and even for those who are just starting to see how it works. It hinders scalability, because by persisting everything in the server memory, if you have a farm environment, each server has its own memory, and then we may have problems. It may not be your case at the moment, but it is interesting to always build things thinking about the future (your application can grow).

Userid Provider

This one is similar to the "in memory", however this supports farm environment, because it makes use of cookies in the client, allowing different servers access these cookies of the customer. However, here the server does not maintain a list of connected users. As long as you don’t have to send notifications to specific users in a group, that is, notifications will always be to the entire group (with the option of deleting the customer that originated the call itself), that would be ok. The problem is that if the server restarts or a Recycle occurs in the IIS pool, the server(s) loses(m) all group settings.

External Persistence

That’s exactly the example you mentioned with the database. You persist with group information and connections in a database, and you no longer lose this information after a Recycle in the IIS pool, nor when the user clears the browser cookies, and supports farm. The only downside of this is that by having to persist in a database, it gets a little slower to connect and send messages, which could also be solved with distributed caching (on a more solid architecture).

But I wouldn’t even think about caching at this point. Standard database, keep the data there, doing tests. If you start to have a very high notification flow for that particular Hub, then you start to think in cache.

To see more about these connection x user persistence templates, see documentation of the Signalr.

I hope I’ve cleared up your doubts, and that it helps you decide what strategy to adopt for your particular case.