page_type | languages | products | urlFragment | name | description | ||||||
---|---|---|---|---|---|---|---|---|---|---|---|
sample |
|
|
azure-sql-blazor-tag-game-sample |
Tag App - Azure SQL + Blazor WebAssembly + Azure Functions SQL bindings Sample |
A sample Blazor WASM online game with the backend APIs implemented with Azure SQL bindings for Azure Functions.
|
Demo environment available at https://aka.ms/buildtag
File/folder | Description |
---|---|
APIs | Azure Functions project folder, backend APIs. |
BlazorWASM | Blazor WebAssembly project folder, frontend web UI. |
SqlDB | SQL project folder, data storage. |
- VS Code
- Docker
- .NET SDK 6.0.408 or newer
- Azure Functions Core Tools
- Static Web Apps CLI
- (optional) SignalR endpoint
The SQL database objects are defined in the SQL project folder and can be deployed to a local development environment using the SQL Database Projects extension in VS Code or Azure Data Studio. More information on publishing a SQL project to a container for local development is available in the SQL Database Projects documentation.
Copy the local.settings.sample.json
file to local.settings.json
and update the connection string to point to your local SQL instance.
Across 3 terminals:
- in APIs folder, start the Azure Functions local runtime to serve the APIs:
func start
- in BlazorWASM folder, start the Blazor WebAssembly app:
Note: The DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER
is used to disable dotnet from automatically opening a window after watch completes. We'll be running swa
to host the content in the next step so the extra browser window is unnecessary.
SET DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER=1
dotnet watch
- in any folder, start the Static Web Apps CLI to serve the static web app and proxy API requests to the Azure Functions local runtime:
swa start http://localhost:5001 --api-location http://127.0.0.1:7071
The following are the steps required to deploy this sample to Azure and enable continuous deployment workflows for all 3 components (APIs, Blazor, and SQL).
-
Create an Azure Functions app and place the publish profile in the GitHub secrets as
AZUREAPPSERVICE_PUBLISHPROFILE
. This enables the sample workflow functions-deploy.yml to deploy the Azure Functions. More information: https://learn.microsoft.com/azure/azure-functions/functions-how-to-github-actions?tabs=dotnet -
Create an Azure SQL Database and place the connection string in the GitHub secrets as
SQLDB
. This enables the sample workflow sql-deploy.yml to deploy the database objects. More information: https://learn.microsoft.com/azure/azure-sql/database/single-database-create-quickstart -
Add an application setting for
SqlConnectionString
to the Azure Functions app with the connection string to the Azure SQL Database. This enables the Azure Functions to connect to the database. More information: https://docs.microsoft.com/azure/azure-functions/functions-how-to-use-azure-function-app-settings?tabs=portal#settings -
Create an Azure SignalR resource in the
Serverless
service mode and place the connection string in the Azure Functions application settings asAzureSignalRConnectionString
. This enables the Azure Functions to connect to the SignalR service and provides real-time scoreboard updates when a user is tagged. More information: https://learn.microsoft.com/azure/azure-signalr/signalr-quickstart-dotnet-core#create-an-azure-signalr-resource -
Create an Azure Static Web App, leaving the
API
location blank and setting it to theStandard
plan. Linking the static web app to your repository will create a GitHub Action workflow that will build and deploy the static web app, similar to static-web-apps-deploy.yml. More information: https://learn.microsoft.com/azure/static-web-apps/functions-bring-your-own -
If you did not link the Azure Static Web App to the Azure Functions app during creation, link the Azure Functions to the Azure Static Web App. More information: https://learn.microsoft.com/static-web-apps/functions-bring-your-own#link-an-existing-azure-functions-app
- sends X and Y coordinates in query string
- returns gamepieces in the 4 nearest squares
SQL bindings:
- Stored procedure SQL input binding with parameters from request query string values
- sends userid in query string
- returns scores for a user
SQL bindings:
- Query text SQL input binding with parameter from request query string value
- sends userid and passkey in request header
- returns current user info
SQL bindings:
- Imperative binding for a stored procedure SQL input binding with parameters from request header values
- sends userid and passkey in request header, userinfo (including color) in request body
- returns updated userinfo
SQL bindings:
- Imperative binding for a stored procedure SQL input binding with parameters from request header values
- Table output binding with content from request body
- sends new user passkey in request body
- returns new saved user info
SQL bindings:
- Stored procedure SQL input binding with no parameters
- Table output binding with passkey from request body and output from stored procedure
- sends userid and passkey in request header, move direction in request URL path
- returns confirmation the user was moved
SQL bindings:
- Query text SQL input binding with parameter from request query string value
- Imperative binding for a stored procedure SQL input binding with parameters from request header values
- Imperative binding for a stored procedure SQL input binding with parameters calculated in function
- Table output binding with output from combined information from input binding and imperative bindings
- when a row is inserted into the Tag.Moves table, the function is started
- the location is checked for other users and 1 is selected at random to be "tagged"
- the tagged user's score is updated with a rainbow
- a SignalR output binding sends a message to the tagged user which refreshes their scoreboard view
SQL bindings:
- SQL trigger
- Imperative binding for a SQL query input binding with parameters from trigger payload
- Imperative binding for a stored procedure SQL input binding for the user selected at random
- client sends userid as a querystring to the negotiate endpoint, configuring the user to receive messages
- broadcast endpoint sends a message to users
Both endpoints are configured for the "scoreboard" SignalR hub name.
- first load of the page
- setup a user
- get a new userid from server, request with a new password (both guids)
- store the userid and password in local storage
- user sets name and selects from 6 colors for token
- update user info on server with name and token color
- place user at 0,0 on board
- setup a user
- every load of the page
- get user position on the board
- get the overall board state
- nearest 4 tiles
- whenever a user moves
- send move to server
- get move result
- update user position on board
- update board state
- update user info/scoreboard
- user
- userid
- password
- name
- token color
- x
- y
- scoreboard
- userid
- count per color
- user moves
- userid
- move number
- move direction
- move result
- move time
- Azure SQL bindings for Azure Functions: https://aka.ms/sqlbindings
- SQL Database Projects for VS Code and Azure Data Studio: https://aka.ms/azuredatastudio-sqlprojects