Azure SignalR Service | Asp.Net Web Api | Console client

Question

I am able to connect to Azure SignalR Service from Asp.Net Web Application using its Access-Key. Asp.Net Web App creates and hosts a hub over Azure SignalR Service. I created ac# console client and connected to Asp.Net Web Application's SignalR Hub using Microsoft.AspNetCore.SignalR.Client library.

Questions:

1. Should I always implement a middleware like Asp.Net Web Application and rely on it to create and talk over Hub? Yes, based on Samara & other sources, we have a couple of choices.

   • Consume REST API from console app to host a hub ( Azure SignalR ) as a server and serve the clients\\ subscribers as portal. This supports uni-directional messaging.
   • Consume REST API from Azure Functions ( make it serverless ) to host a hub ( Azure SignalR ) as a server and serve the clients\\ subscribers as portal. This supports uni-directional messaging.
   • Host a hub ( Azure SignalR ) from Asp.Net managed Web API with auth() layer and cater clients via API. This supports fully blown bi-directional messaging.

2. Is it not possible to directly talk to Azure SignalR Service from c# console to create a Hub and send my messages over Hub?

   • Consume REST API from console app to host a hub ( Azure SignalR ) as a server and serve the clients\\ subscribers as portal. This supports uni-directional messaging.
   • Consume REST API from Azure Functions ( make it serverless ) to host a hub ( Azure SignalR ) as a server and serve the clients\\ subscribers as portal. This supports uni-directional messaging.

I am new to Azure SignalR Service; please assist me on above questions. My questions are almost answered. Hope it helps!

PS People does not have real answers, stay away

Answer 1

I think I understand your question a bit better. I think you are talking about the sample code here? https://github.com/aspnet/AzureSignalR-samples/tree/master/samples/Serverless

If you want to make a chat application you would modify the code to combine the two functions. I was able to do this by updating the program.cs to run both code sets. It isn't a complete chat client- all messages still say they are coming from the other user, but I hope it gives you a better idea of how this works.

    app.Command("client", cmd =>
    {
        cmd.Description = "Start a client to listen to the service";
        cmd.HelpOption("--help");

        var userId = cmd.Argument("<userId>", "Set User ID");

        cmd.OnExecute(async () =>
        {
            var connectionString = connectionStringOption.Value() ?? configuration["Azure:SignalR:ConnectionString"];

            if (string.IsNullOrEmpty(connectionString) || !hubOption.HasValue())
            {
                MissOptions();
                return 0;
            }

            var client = new ClientHandler(connectionString, hubOption.Value(), userId.Value);

            await client.StartAsync();

//Add the server to the client so we can talk both ways
            var server = new ServerHandler(connectionString, hubOption.Value());
            await server.Start();


            Console.ReadLine();
            await client.DisposeAsync();

            return 0;
        });
    });

There is something to keep in mind, and why most of these examples add an API layer over the top of the SignalR service. In order to create a connection to the service, you are using a key. If you embed that into your console app and then distibute it, anyone with the app now has the ability to control all of your hubs by extracting the key . Unless you trust all your users with this power, then adding an API layer is the way to go- the user authenticates to the API, and the API decides what permissions they have on the hub.