Anthony Chu

Azure Cosmos DB has a nifty change feed feature that tracks create and update events on documents in a collection. Applications, including serverless apps built with Azure Functions, can read events from the change feed and listen to new events on the change feed in real-time.

Azure SignalR Service is a managed service that allows applications to broadcast real-time messages to many connected clients over WebSockets and other supported transports.

September 24, 2018 - Azure SignalR Service is now generally available!

March 6, 2019 - SignalR Service bindings for Azure Functions are now generally available!

In this article, we'll look at how we can use Azure Functions and SignalR Service to broadcast real-time document changes in Cosmos DB to clients over WebSockets.

Overview

Here's how all the pieces fit together.

1. A document is created or updated in Cosmos DB.
2. The change or update event is automatically logged in the Cosmos DB change feed.
3. Using the Cosmos DB trigger, an Azure Function is invoked when the event appears in the change feed.
4. Using the SignalR Service output binding, the function outputs a message to SignalR Service.
5. SignalR Service sends the message to all connected clients over WebSockets.

The SignalR client SDK is available in JavaScript and .NET Standard. There's also a Java client coming soon. We'll use a simple Vue.js app in a browser for this project. Using the .NET Standard SDK, we can also build desktop apps with .NET Framework and .NET Core or mobile apps with Xamarin to receive messages from SignalR Service.

In recent years, there's been a shift towards building applications with serverless architectures. Serverless backends are typically powered by fully managed and infinitely scalable services with consumption-based pricing, such as Azure Functions and Logic Apps.

Today, Azure Storage announced the public preview of its static website hosting feature that complements serverless backends by making it easy to also host frontend single page applications (SPAs) in a fully managed, highly scalable, consumption-based service. Blob Storage has always been able to serve static assets such as HTML, CSS, and JavaScript. The static websites feature adds more traditional web server capabilities that are required to host SPAs and statically generated websites, including support for defining default and error pages.

Blazor is an experimental framework from the ASP.NET team for building SPAs using .NET instead of JavaScript. It does this by running standard .NET DLLs in the browser on top of a Mono runtime that has been compiled to WebAssembly.

• Blog post announcing Azure Storage static websites
• Documentation on the static websites feature
• ASP.NET Blazor

In this post, we'll look at how to host a standalone Blazor application with no server-side code in a Azure Blob Storage static website.

Update May 14, 2018 - The app setting WEBSITE_USE_ZIP is now WEBSITE_RUN_FROM_ZIP. This article as been updated to reflect this.

Yesterday, Azure announced a new way to deploy our applications to Azure Functions and App Service called Run-From-Zip, currently in preview. It allows us to mount the contents of a zip file into wwwroot instead of copying files into that folder.

In this article we'll take a look at how to use Visual Studio Team Services (VSTS) to build and deploy an application to Azure Functions and Azure Web Apps.

Service Fabric can dynamically assign ports to a service. For stateless and stateful services, the Service Fabric SDK makes it easy to configure our services to listen to the dynamically assigned ports. But what about guest executables, especially ones that are precompiled and we cannot or do not want to modify the source code?

We'll look at how to configure ports for two sample Windows guest applications without modifying the source code:

• A Go application that takes a port number as a command line argument
• A self-contained ASP.NET Core application that can be configured using the ASPNETCORE_URLS environment variable

A couple of months ago, AzCopy was quietly added to Windows App Service and Azure Functions worker instances at D:\devtools\AzCopy\AzCopy.exe. It is used to upload files to blob storage from the command line. App Service allows the running of arbitrary scripts during deployment, meaning that there are a couple of scenarios that are now possible by calling AzCopy during App Service Git deployment, including deployments with a "Deploy to Azure" button:

• Upload files to blob storage for serving from a CDN during a Web App deployment
• Upload a single page application (SPA) frontend to blob storage during an Azure Function App deployment

Today, we'll use Joe Raio's popular Azure Functions Tug of War demo app to show how to upload the app's frontend assets to blob storage during deployment.