I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.
As I learn with Blazor I will blog about it as a series of articles.
This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.
Earlier articles in this series:
- Part 1 - State
- Part 2 - Better State
- Part 3 - Components
- Part 4 - Render Mode
- Part 5 - Client IP
- Part 6 - Azure Cosmos DB
SignalR is at the heart of Blazor server. It forms the realtime connection so that the server can send updates to the browser.
SignalR is describes as:
"SignalR is a free and open-source software library for Microsoft ASP.NET that allows server code to send asynchronous notifications to client-side web applications. The library includes server-side and client-side JavaScript components."
But it is almost an invisible part of Blazor - it just happens.
For production use however, you really want to be using an Azure SignalR Service as it takes a lot of the strain off the server and allows for greater scaling.
"We recommend using the Azure SignalR Service for Blazor Server apps. The service allows for scaling up a Blazor Server app to a large number of concurrent SignalR connections. In addition, the SignalR service's global reach and high-performance data centers significantly aid in reducing latency due to geography." Source
Creating an Azure SignalR Service
Again, like Azure Cosmos DB, there is a free tier.
Its intended for development & test, but given the expected usage of my survey, it was to be sufficient for my use.
Creating via the Azure Portal is easy and provides you with the relevant credentials. (In a future article, I'll show how to create with Azure Bicep - a Domain-Specific-Language for producing ARM templates).
You'll need the connection string from the service.
For production, I run the Blazor Server App as an Azure App Service, thus set the environment variable (Configuration -> Application Setting) Azure__SignalR__ConnectionString
to the connection string (more on this in the Azure Bicep article).
For development, I set the User Secret of Azure:SignalR:ConnectionString
.
The important thing is to make sure that the connection string is NOT stored in source control (especially as I'm using a public Github repository).
Configuring Blazor app to use the Azure SignalR Service
With Startup.cs
add:
public void ConfigureServices(IServiceCollection services)
{
...
services.AddSignalR().AddAzureSignalR();
...
}
And within appsettings.json
, then add:
"Azure": {
"SignalR": {
"Enabled": "true",
"ServerStickyMode": "Required"
}
}
Scaffolding
A lot of this setup is done for you if you scaffold the SignalR Service connection - either when you create the Blazor Server app at the start or by the "Connected Services".
Once all of this is done, it should just all work.
Its almost too easy. And so far I've found no problems with it.
Top comments (8)
Hi Mark, I really liked your tutorial, about the Survey, I installed Cosmos DB Emulator, created the SignalR Service in Azure, and when I started the application the message is "This survey is currently closed.". Does this mean the database has to be created/populated with questions? Do you have some sample data for it?
You just need to run the app in test mode. Simply append ?IsTest to the url
The default mode is production -for which the survey is now closed. However, just specifying ?IsTest will load the actual survey logic.
Using the ?IsTest allowed me (when the app is in production) to run slightly different logic (hopefully that makes sense)
Yes, it works now, but after I finish and save the results "An error has occurred while trying to save your details" was shown.
I assume you've installed CosmosDB locally? If not see docs.microsoft.com/en-us/azure/cos...
You can also try to step through the CosmosDbPersistanceManager Persist method - break on line 44 & 50 to see why it is failing to save.
Yes, I installed CosmosDB locally. Now I realize the Emulator has to be started, whilst running the app. I can see it saved the input data, in something like JSON format.
Would you consider continuing your application? Like report the actual survey results, user management etc, and deploy the whole app to Azure.
The app is deployed to Azure. There are Azure Pipeline YAML in the repo for it.
In terms of reporting; I had planned to use Jupyter notebooks to produce some analysis, then surface them to the website using something like d3.js
But as I had only a single respondent, I didn't take it any further forwards.
I'd no plans to add user management as it was always intended to be fairly single use.
Ok, sounds good. Great work 😊