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 a c# 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!

P.S. 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.