Forem: Anthony Chu

Overcoming Serverless challenges with Durable Functions

Anthony Chu — Tue, 29 Sep 2020 05:26:52 +0000

Serverless functions are great for running code without worrying about managing infrastructure. You can create stateless functions that run for short periods of time. However, there are times when you need longer-running functions that persist state, such as a workflow that runs for hours, days, or longer.

Azure Functions has a feature called Durable Functions that was designed to solve some of these challenges by adding support for useful, new patterns to serverless functions.

A few patterns made possible by Durable Functions include:

Function chaining - Orchestrate a serverless workflow composed of many functions. These orchestrations can run for extended periods of time.
Fan out / fan in - Call a bunch of functions that all execute in parallel, taking advantage of the highly-scalable compute provided by Azure Functions, then aggregate the results.
Monitor - Call a function repeatedly until a condition is met.

These are just a sampling of capabilities provided by Durable Functions. To learn more join me, Durable Functions expert Marc Duiker, and many others at this week's Create: Serverless virtual event!

Create: Serverless is a half day of conversations with serverless community members to discuss how you can run code for any application without having to manage servers.

Rendering PDFs with Razor Templates and PuppeteerSharp in Azure Functions

Anthony Chu — Sun, 13 Sep 2020 05:29:09 +0000

A couple of weeks ago, we looked at how to use Puppeteer with Node.js Azure Functions to take screenshots of web pages. Today, we'll look at how to render PDFs in Azure Functions using Razor and the C# port of Puppeteer, PuppeteerSharp.

A common usage of this is generating something like an invoice. We'll create PDF invoices for our favorite fictitious online store, Tailwind Traders.

Overview

We'll run ASP.NET Core Razor Pages in a .NET Azure Functions app and use PuppeteerSharp with headless Chromium to render the invoice Razor template to a PDF.

In the rest of this article, we'll walk though these steps:

Build an ASP.NET Core Razor Pages app that includes a Razor template and other resources required to render the invoice.
Create an Azure Functions app and configure it to run PuppeteerSharp.
Run the ASP.NET Core Razor Pages app in the function app.
Write a function that uses PuppeteerSharp to render the invoice and generate a PDF.
Deploy the app to Azure.

Create an ASP.NET Core Razor Pages app

We'll use a typical ASP.NET Core Razor Pages app to render our invoice. It's just a simple project created with dotnet new webapp.

In the app, we'll create a form that has a single textbox. Puppeteer will populate the form with some JSON data to pass to the Razor page. When the form is submitted, the Razor renders an invoice.

This is the Razor code.

@page
@model IndexModel

<div class="text-center">
  @* <h1 class="display-4"><img class="logo" src="img/functions.svg" /> Invoice</h1> *@

  <div class="logo">
    <img class="logo" src="img/ttlogo.png" />
  </div>
  @if (Model.Items == null)
  {
    <div>
      <form id="invoice-form" method="post">
        <textarea name="items" id="items-box"></textarea>
        <input type="submit" id="submit-button" value="Submit" />
      </form>
    </div>
  }
  else
  {
    <div>
      <table class="table">
        <thead>
          <tr>
            <td>Item #</td>
            <td>Name</td>
            <td>Price</td>
            <td>Quantity</td>
            <td>Line Total</td>
          </tr>
        </thead>
        <tbody>
          @foreach(var item in Model.Items)
          {
            <tr>
              <td>@item.ProductId</td>
              <td>@item.Name</td>
              <td>@item.UnitPrice.ToString("F2")</td>
              <td>@item.Quantity</td>
              <td>@((item.UnitPrice * item.Quantity).ToString("F2"))</td>
            </tr>
          }
          <tr>
            <td colspan="4"></td>
            <td><b>@(Model.Items
                    .Select(i => i.UnitPrice * i.Quantity)
                    .Sum()
                    .ToString("F2"))</b></td>
          </tr>
        </tbody>
      </table>
    </div>
  }
</div>

And this is the OnPost method that takes the JSON invoice data and converts it into the page model.

public void OnPost()
{
    var options = new JsonSerializerOptions
    {
        PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
    };
    var itemsJson = Request.Form["items"].First();

    Items = JsonSerializer.Deserialize<IEnumerable<InvoiceItem>>(itemsJson, options);
}

For more information on how to get started with Razor Pages, check out this tutorial.

To test this out, run dotnet run and submit some products in the box.

Use PuppeteerSharp in C# Azure Functions

In a separate project, we'll create an Azure Functions app. In the app, add a reference to PuppeteerSharp.

While the Node.js Puppeteer package downloads Chromium during npm install, PuppeteerSharp doesn't. Instead, we need to use the BrowserFetcher class in our app to download the browser.

We can configure our function app to download the browser at startup.

public override void Configure(IFunctionsHostBuilder builder)
{
    var bfOptions = new BrowserFetcherOptions();
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
    {
        bfOptions.Path = Path.GetTempPath();
    }
    var bf = new BrowserFetcher(bfOptions);
    bf.DownloadAsync(BrowserFetcher.DefaultRevision).Wait();
    var info = new AppInfo
    {
        BrowserExecutablePath = bf.GetExecutablePath(BrowserFetcher.DefaultRevision)
    };
    builder.Services.AddSingleton(info);
}

Notice that on Linux, we're downloading to the machine's temp folder. We need to do this because when we deploy it to the Linux Consumption plan in Azure, the default download location (the app's bin folder) is readonly.

After the browser is downloaded, we stash the path of the executable into an AppInfo object that can be injected into our functions. We'll reference this in order load the browser from the same location it was downloaded to.

Note: Downloading the app at function app startup will increase cold start time significantly. If you find that cold start is too slow, explore other ways to download the browser, such as downloading it to shared mounted storage. This storage can be shared between different function app instances, so subsequent instances do not have to download the browser again.

Reference and start the Razor app from Azure Functions

Now that we have a Razor Pages app and a function app, we need to integrate the two together.

In the function app, we add a reference to the Razor Pages app.

dotnet add reference ../RazorPagesApp/RazorPagesApp.csproj

This builds and copies the binaries from the Razor Pages app to the function app. Since we have some static resources like images, we need to configure those to be copied over as well. To do this, we update the function app's project file to copy over the Razor Pages app's wwwroot folder.

<ItemGroup>
  <Content Include="..\RazorPagesApp\wwwroot\**" Link="wwwroot\%(RecursiveDir)%(Filename)%(Extension)" CopyToOutputDirectory="Always" />
</ItemGroup>

In order for Puppeteer's headless Chromium browser to render the invoice, we need to expose a local endpoint for the Razor Pages app's ASP.NET Core server. At function app startup, we look for an unused part and start the server. Our Configure method now looks like this:

public override void Configure(IFunctionsHostBuilder builder)
{
    var bfOptions = new BrowserFetcherOptions();
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
    {
        bfOptions.Path = Path.GetTempPath();
    }
    var bf = new BrowserFetcher(bfOptions);
    bf.DownloadAsync(BrowserFetcher.DefaultRevision).Wait();
    var info = new AppInfo
    {
        BrowserExecutablePath = bf.GetExecutablePath(BrowserFetcher.DefaultRevision)
    };

    var port = GetAvailablePort();
    info.RazorPagesServerPort = port;
    builder.Services.AddSingleton(info);

    var webHost = Host.CreateDefaultBuilder()
        .ConfigureWebHostDefaults(webBuilder =>
        {
            var scriptRoot = Environment.GetEnvironmentVariable("AzureWebJobsScriptRoot");
            System.Console.WriteLine($"Starting web server on port {port}");
            if (!string.IsNullOrEmpty(scriptRoot))
            {
                webBuilder.UseContentRoot(scriptRoot);
            }

            webBuilder.UseUrls($"http://0.0.0.0:{port}")
                .UseStartup<RazorPagesApp.Startup>();
        })
        .Build();

    webHost.Start();
}

Notice we also stash the selected port in the AppInfo object that can be later accessed by the functions using dependency injection.

Now when we start the function app, it'll ensure the browser is downloaded and start up the Razor Pages app at a random port.

Render the Razor page as a PDF

The last thing we need to add to our app is a function that uses Puppeteer to render the PDF.

public class GeneratePdf
{
    private readonly AppInfo appInfo;

    public GeneratePdf(AppInfo browserInfo)
    {
        this.appInfo = browserInfo;
    }

    [FunctionName("GeneratePdf")]
    public async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req,
        ILogger log)
    {
        var browser = await Puppeteer.LaunchAsync(new LaunchOptions
        {
            Headless = true,
            ExecutablePath = appInfo.BrowserExecutablePath
        });
        var page = await browser.NewPageAsync();
        await page.GoToAsync($"http://localhost:{appInfo.RazorPagesServerPort}/");

        var data = GetData();
        await page.TypeAsync("#items-box", data);
        await Task.WhenAll(
            page.WaitForNavigationAsync(), 
            page.ClickAsync("#submit-button"));
        var stream = await page.PdfStreamAsync();
        await browser.CloseAsync();

        return new FileStreamResult(stream, "application/pdf");
    }
}

The function uses Puppeteer to start a headless Chrome browser, open the input form in the Razor Pages app, submit the invoice data to render the invoice, and generate a PDF from the web page.

Deploy to Azure

Because the app takes care of downloading Chromium and our app is configured to download it to the correct location, there's nothing special we need to do to deploy the app. Remember that headless Chromium only works on Linux. We can deploy it to the Linux Consumption plan.

Resources

Running headless Chromium in Azure Functions with Puppeteer and Playwright

Anthony Chu — Tue, 18 Aug 2020 06:44:01 +0000

With a recent update to Azure Functions, it is now possible to run headless Chromium in the Linux Consumption plan. This enables some serverless browser automation scenarios using popular frameworks such as Puppeteer and Playwright.

Browser automation with Puppeteer and Playwright

Browser automation has been around for a long time. Selenium WebDriver was a pioneer in this space. More recently, Puppeteer and Playwright have gained in popularity. The two frameworks are very similar. Google maintains Puppeteer and Microsoft maintains Playwright. It's interesting to note that some of the folks who worked on Puppeteer are now working on Playwright.

Puppeteer and Playwright each support a different set of browsers. Both of them can automate Chromium. They automatically install Chromium and can use it without extra configuration.

Azure Functions support for headless Chromium

It's been a challenge to run headless Chromium on Azure Functions, especially in the Consumption (serverless) plan. Until now, the only way to run it has been by using a custom Docker image on the Premium plan.

Very recently, the necessary dependencies to run headless Chromium were added to the Azure Functions Linux Consumption environment. This means that we can simply npm install Puppeteer or Playwright in a Node.js function app to start using one of those frameworks to interact with Chromium.

Use Puppeteer and Playwright in Azure Functions

It's pretty straightforward to run either Puppeteer or Playwright in Azure Functions. We use npm to install it. Note that because it is needed at run-time, we should install the package as a production dependency. In the examples below, we use Puppeteer/Playwright with headless Chromium in an HTTP triggered function to open a web page and return a screenshot.

Puppeteer



# also installs and uses Chromium by default
npm install puppeteer



const puppeteer = require("puppeteer");

module.exports = async function (context, req) {
    const url = req.query.url || "https://google.com/";
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await page.goto(url);
    const screenshotBuffer = 
        await page.screenshot({ fullPage: true });
    await browser.close();

    context.res = {
        body: screenshotBuffer,
        headers: {
            "content-type": "image/png"
        }
    };
};

Playwright

Note: Playwright 1.4.0 requires some dependencies that are not installed in the Linux Consumption plan. Use 1.3.0 until this issue is resolved.



# the default playwright package installs Chromium, Firefox, and WebKit
# use playwright-chromium if we only need Chromium
npm install playwright-chromium@1.3.0



const { chromium } = require("playwright-chromium");

module.exports = async function (context, req) {
    const url = req.query.url || "https://google.com/";
    const browser =  await chromium.launch();
    const page = await browser.newPage();
    await page.goto(url);
    const screenshotBuffer = 
        await page.screenshot({ fullPage: true });
    await browser.close();

    context.res = {
        body: screenshotBuffer,
        headers: {
            "content-type": "image/png"
        }
    };
};

For the full source, take a look at this repo. When we run the function app locally and visit http://localhost:7071/api/screenshot?url=https://bing.com/, we get back a screenshot of the page.

Deploy to Azure

Since we're deploying to a Linux environment, we have to make sure we run npm install in Linux so it downloads a version of Chromium that matches the deployment target. Thankfully, Azure Functions supports remote build so that the app is built in the correct Linux environment during deployment, even though we might be developing locally in macOS or Windows.

Configuring VS Code for remote build

If we are deploying using Azure Functions Core Tools, we can skip this step.

By default, the Azure Functions VS Code extension will deploy the app using local build, which means it'll run npm install locally and deploy the app package. For remote build, we update the app's .vscode/settings.json to enable scmDoBuildDuringDeployment.



{
    "azureFunctions.deploySubpath": ".",
    "azureFunctions.projectLanguage": "JavaScript",
    "azureFunctions.projectRuntime": "~3",
    "debug.internalConsoleOptions": "neverOpen",
    "azureFunctions.scmDoBuildDuringDeployment": true
}

We can also remove the postDeployTask and preDeployTask settings that runs npm commands before and after the deployment; they're not needed because we're running the build remotely.

And because we're running npm install remotely, we can add node_modules to .funcignore. This excludes the node_modules folder from the deployment package to make the upload as small as possible.

Creating a Linux Consumption function app

We can use any tool, such as the Azure Portal or VS Code, to create a Node.js 12 Linux Consumption function app in Azure that we'll deploy the app to.

Configuring Chromium download location (Playwright only)

By default, Playwright downloads Chromium to a location outside the function app's folder. In order to include Chromium in the build artifacts, we need to instruct Playwright to install Chromium in the app's node_modules folder. To do this, create an app setting named PLAYWRIGHT_BROWSERS_PATH with a value of 0 in the function app in Azure. This setting is also used by Playwright at run-time to locate Chromium in node_modules.

Publishing the app

If using VS Code, we can use the Azure Functions: Deploy to Function App... command to publish the app. It'll recognize the settings we configured earlier and use remote build.

If using Azure Functions Core Tools, we need to run the command with the --build remote flag:



func azure functionapp publish $appName --build remote

And that's it! We've deployed a consumption Azure Functions app that uses Puppeteer or Playwright to interact with Chromium!

Resources

Authenticate Blazor WebAssembly with Azure Static Web Apps

Anthony Chu — Tue, 28 Jul 2020 07:37:59 +0000

Azure Static Web Apps is a great place to host Blazor WebAssembly apps. Among Static Web Apps' many features, it has built-in support for authentication using social logins. In this article, we'll look at how we can take advantage of Static Web Apps Authentication in our Blazor WebAssembly apps.

Overview

Azure Static Web Apps takes care of dealing with identity providers like GitHub, Twitter, and Facebook. The frontend application can then access the user's credentials using a built-in API.

Blazor WebAssembly supports custom authentication providers. We'll look at how to set up an auth provider for Static Web Apps and use it in the app. We'll also look at how to properly secure certain functionality in the app so that only authenticated users have access.

Azure Static Web Apps will soon have native support for building and deploying Blazor WebAssembly. For now, take a look at Tim Heuer's article on how to deploy it.

Basic setup

To set up a Blazor WebAssembly app for Static Web Apps Authentication, we need to install the auth provider. Then we need to register it and update the routing to use the logged in user's identity.

Install NuGet package

To simplify setup, I created a NuGet package containing an authentication state provider for Azure Static Web Apps. In a Blazor WebAssembly app, install the package:

dotnet add package AnthonyChu.AzureStaticWebApps.Blazor.Authentication --version 0.0.2-preview

Register services

After the package is installed, use AddStaticWebAppsAuthentication() in the app's Program.cs to register the Static Web Apps AuthenticationStateProvider and other necessary services.

using System;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Components.WebAssembly.Hosting;
using Microsoft.Extensions.DependencyInjection;
using AzureStaticWebApps.Blazor.Authentication;

namespace BlazorLogin
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
            builder.RootComponents.Add<App>("app");

            builder.Services
                .AddTransient(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) })
                .AddStaticWebAppsAuthentication();
            await builder.Build().RunAsync();
        }
    }
}

Update App.razor

The out-of-the-box template for Blazor WebAssembly doesn't use authentication. Update App.razor to enable authentication by adding <CascadingAuthenticationState> and changing the <RouteView> component to <AuthorizeRouteView>. This exposes the authentication state as a cascading parameter throughout the app.

<CascadingAuthenticationState>
    <Router AppAssembly="@typeof(Program).Assembly">
        <Found Context="routeData">
            <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
        </Found>
        <NotFound>
                <LayoutView Layout="@typeof(MainLayout)">
                    <p>Sorry, there's nothing at this address.</p>
                </LayoutView>
        </NotFound>
    </Router>
</CascadingAuthenticationState>

For more information on how to set this up, check out the Blazor security docs.

User authentication

Now the that basic setup is complete, we can add some login links to allow our users to sign in. Then we will look at ways to access the user's identity in our components.

Adding login links

Azure Static Web Apps Authentication provides some links for users to log in and out of services. For instance, to log into GitHub, send the user to /.auth/login/github. And to log out, send them to /.auth/logout.

We create a page named LoginProvider.razor that displays the login buttons.

@page "/login-providers"

@{
    var providers = new Dictionary<string, string>
    {
        { "github", "GitHub" }, 
        { "twitter", "Twitter" },
        { "facebook", "Facebook" }
    };
}

<h1>Login</h1>

<div class="container">
    @foreach(var provider in providers)
    {
        <div class="row">
            <div class="col-sm-12 col-md-9 col-lg-6">
                <a class="btn btn-block btn-lg btn-social btn-@provider.Key" href="/.auth/login/@provider.Key">
                    <span class="fa fa-@provider.Key"></span> Sign in with @provider.Value
                </a>
            </div>
        </div>
    }
</div>

This is what it looks like if we run the app and go to this page:

Accessing user's identity

After the user is logged in, they are redirected back to the app. This time, the authentication state component sees that the user is logged in and it populates a ClaimsPrincipal with the user information and roles. To access this information in a page or component, use context.User. We can also use <AuthorizeView> to decide what to display based on authentication state.

<AuthorizeView>
    <Authorized>
        Hello, @context.User.Identity.Name!
        <a href="/.auth/logout?post_logout_redirect_uri=/">Log out</a>
    </Authorized>
    <NotAuthorized>
        <a href="/login-providers">Log in</a>
    </NotAuthorized>
</AuthorizeView>

Running locally

The authentication state provider uses Azure Static Web Apps' /.auth/me endpoint to retrieve information from the logged in user. If we want to test authentication locally, we can configure StaticWebAppsAuthentication:AuthenticationDataUrl in appsettings.Development.json to use a sample JSON file instead.

{
  "StaticWebAppsAuthentication": {
    "AuthenticationDataUrl": "/sample-data/me.json"
  }
}

For an example of what goes in that JSON file, take a look at the Static Web Apps docs on client principal data.

Because we only configure it in appsettings.Development.json, this only changes the setting when debugging locally. Change the contents of the file to simulate an authenticated or anonymous user.

Access control

We can lock down our application based on the authentication state. Because this is a client application, we must understand that all pages and data in the Blazor WebAssembly app (including protected pages and data in appsettings.json files) are publicly accessible. If we need to secure data, we must protect it in a properly secured backend API.

In this example, we want to protect the "Fetch Data" page. This page returns random weather information. To properly secure it, we must hide navigation link and the page from unauthenticated users. We must also ensure that the API that serves the weather data is only accessible by authenticated users.

Conditionally showing page in navigation

In NavMenu.razor, we only want to display the "Fetch Data" menu item to authenticated users. Like we did before, we can do this using the <AuthorizeView> component.

<AuthorizeView>
    <Authorized>
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="fetchdata">
                <span class="oi oi-list-rich" aria-hidden="true"></span> Fetch data
            </NavLink>
        </li>
    </Authorized>
</AuthorizeView>

Preventing page from displaying to anonymous users

And to protect the FetchData.razor page from being shown to unauthenticated users, we simply need to add an Authorize attribute to it at the top.

@attribute [Authorize()]

Now if we tried to browse to /fetchdata, we'll get this message:

Blocking access to API

But simply locking down links and pages in the client aren't enough. An anonymous user can still retrieve data from our fetch data API directly.

So we need to prevent unauthenticated users from accessing the get weather API. In Azure Static Web Apps, APIs are built using Azure Functions.

Note that only Node.js functions are currently supported. .NET function support is coming soon.

Static Web Apps allows us to define server-side routing rules using a routes.json file.

{
  "routes": [
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/*",
      "serve": "/index.html",
      "statusCode": 200
    }
  ]
}

This file defines two routing rules. The first one restricts access to all backend functions at /api/* to authenticated users only. The second one is a standard single page application fallback route that allows deeplinking to work.

Note that there will be a new configuration file coming soon that supports enhanced route definitions and other settings. routes.json will continue to be supported for the foreseeable future.

For a complete sample app, check out the GitHub repo.

Conclusion

And that's the basics for how to use Azure Static Web Apps Authentication with Blazor WebAssembly. For details on how the AuthenticationStateProvider is built, take a look at the source code.

Resources

Azure Functions and App Service Authentication with Auth0 and other OpenID Connect providers

Anthony Chu — Thu, 23 Jul 2020 16:34:04 +0000

Azure Functions and Azure App Service recently added integration with OpenID Connect (OIDC) providers. We can now use any OpenId Connect compliant provider to authenticate users in our apps.

In this article, we'll look at how to configure Auth0 with Azure Functions. The same steps can be used to configure any other OIDC provider and can also be applied to Azure App Service.

Overview

To integrate an OpenID Connect provider with Azure Functions, we need to follow these steps:

Obtain a client id and secret plus other config settings from the OIDC provider.
Create an authentication config file in our app and add the relevant information from the OIDC provider to the file.
Supply the client secret in an app setting.
Enable file-based authentication configuration in the app.

Create an app in Auth0

Auth0 is a popular identity service. It supports login via many social identities as well as with app-specific accounts.

Instead of configuring our function app with social logins like Google or creating a custom username/password database solution, we can rely on Auth0 to manage all that for us and we simply integrate our app with Auth0 using OpenID Connect.

The first thing we need to do to get started is create a free Auth0 account. Then we create an app in Auth0 of type "Regular Web Application".

When the app is created, note the client id and secret.

Note: We need to create a function app in Azure before proceeding with the following steps. Auth0 is going to need to use the app name in some configurations.

In the Application URIs section, fill in these settings:

Application Login URI - https://<app-name>.azurewebsites.net/.auth/login/auth0
Allowed Callback URLs - https://<app-name>.azurewebsites.net/.auth/login/auth0/callback
Allowed Logout URLs - https://<app-name>.azurewebsites.net/.auth/logout

The most important setting is the Allowed Callback URLs, which tells Auth0 about the callback URL that the function app authentication will use.

Note that each URL has a segment with the value auth0. This needs to match the name we give the OIDC provider in the configuration file that we'll cover next.

Click Save Changes. Then click on the subtle Show Advanced Settings link.

In the Endpoints tab, note the OpenID Configuration URL.

Create an authentication config file

Currently, OpenID Connect providers can only be enabled in Azure Functions or App Service using a new file-based configuration. Multiple providers can be configured in the same app.

The config file must be located in the root of the function app. We'll create one named auth.json.

Then we place this content in the file:

{
  "platform": {
    "enabled": true
  },
  "globalValidation": {
    "redirectToProvider": "auth0",
    "unauthenticatedClientAction": "RedirectToLoginPage"
  },
  "identityProviders": {
    "openIdConnectProviders": {
      "auth0": {
        "registration": {
          "clientId": "<auth0_client_id>",
          "clientCredential": {
            "secretSettingName": "AUTH0_CLIENT_SECRET"
          },
          "openIdConnectConfiguration": {
            "wellKnownOpenIdConfiguration": "https://<auth0_tenant_name>.auth0.com/.well-known/openid-configuration"
          }
        },
        "login": {
          "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
          "scope": [ "openid", "profile", "email" ],
          "loginParameterNames": []
        }
      }
    }
  },
  "login": {
    "tokenStore": {
      "enabled": true
    }
  }
}

Replace the values of clientId with the Auth0 client id, and wellKnownOpenIdConfiguration with the OpenID configuration URL from Auth0.

We've also specified some scopes so that we can obtain profile and email information from the customer.

Now that the auth file is added to the app, we publish the app to Azure.

Note that we didn't put the client secret into the file. That's because we don't want to commit it to source control. Instead, we provide the app setting name (AUTH0_CLIENT_SECRET) that we'll use to store that value in Azure.

Add a client secret app setting

In the function app's Configuration page, create an app setting named AUTH0_CLIENT_SECRET. In the value, paste in the Auth0 client secret.

Enable file-based auth configuration

The last step we have to take is enable the use of our new file-based auth config. There's no UI for this yet. We can use an Azure CLI command to do it.

az rest --method put --url https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.Web/sites/$APP_NAME/config/authsettings?api-version=2018-02-01 --body "{\"properties\":{\"enabled\":\"true\",\"isAuthFromFile\":\"true\",\"authFilePath\":\"auth.json\"}}"

The above command updates the app's authsettings properties with the following values:

enabled = true
isAuthFromFile = true
authFilePath = auth.json

Test it out

Now when we try to access the function app in the browser, we're redirected to Auth0. We can create a new account to log in.

In an HTTP triggered function, the authenticated user's information can be obtained from the x-ms-client-principal header. We need to convert it from base64 encoded JSON.

module.exports = async function (context, req) {
  const buffer = Buffer.from(req.headers["x-ms-client-principal"], "base64");
  const user = JSON.parse(buffer.toString("ascii"));

  const email = user.claims.find(c => c.typ === "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress").val;
  const nickname = user.claims.find(c => c.typ === "nickname").val;

  context.res = {
    status: 200,
    body: `Hello ${nickname} [${email}]`
  };
};

This function returns:

Hello anthony [anthony@anthonychu.ca]

Resources

End-to-End Serverless Real-Time IoT with Python

Anthony Chu — Mon, 14 Oct 2019 06:24:55 +0000

Python runs on IoT devices. It runs on Azure Functions. It runs pretty much anywhere!

In this article, we'll look at how to build an end-to-end IoT solution using Python. We'll send telemetry from a device to Azure IoT Hub. Then we'll use Azure Functions and Azure SignalR Service to send messages from IoT Hub to a Python app in real-time.

Send telemetry to Azure IoT Hub using MQTT

Azure IoT Hub is a managed service that facilitates bi-directional communication between your IoT application and the devices it manages. It has a lot of capabilities; we'll use it to ingest telemetry from IoT devices.

IoT Hub supports many protocols, including HTTPS, AMQP, and MQTT. We'll use MQTT to send messages from our IoT device using Python.

It only takes a few lines of code to send messages to IoT Hub over MQTT using the Eclipse Paho library.

import paho.mqtt.client as mqtt

client = mqtt.Client(config.device_id, mqtt.MQTTv311)

client.username_pw_set(iothub_user, sas_token)
client.tls_set()
client.connect(config.hub_address, 8883)

client.loop_start()

while True:
    reading = sensor.read()
    msg = json.dumps(reading)
    client.publish(iot.hub_topic_publish, msg)
    time.sleep(sample_rate_in_seconds)

The full source code in a device simulator can be found on GitHub.

A huge thanks to Dave Glover for helping get Python working with MQTT and IoT Hub.

Relay messages from IoT Hub to Azure SignalR Service with Azure Functions

Now that device(s) are sending messages to IoT Hub, we need a way of receiving them. One of the easiest ways to do this is using Azure Functions. With the Event Hubs trigger (which can be used with IoT Hub's built-in Event Hubs compatible endpoint), Azure Functions does all the work for us and will execute our Python code whenever a message appears in IoT Hub.

When a message is received from IoT Hub, we want to broadcast it to clients in real-time using WebSockets. Azure SignalR is a managed real-time messaging service in Azure that does this really well. We can integrate it with Azure Functions using an output binding.

The Azure Function is configured using the following function.json file. The function is triggered by messages in IoT Hub, and it has a single output binding for sending messages over SignalR Service:

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "type": "eventHubTrigger",
      "name": "event",
      "direction": "in",
      "eventHubName": "my-hubname",
      "connection": "EventHubConnectionString",
      "cardinality": "one",
      "consumerGroup": "$Default"
    },
    {
      "type": "signalR",
      "direction": "out",
      "name": "$return",
      "hubName": "devicemessages"
    }
  ]
}

The actual Python function in __init__.py is just a few lines of code:

def main(event: func.EventHubEvent):
    event_json = event.get_body().decode('utf-8')
    event_item = json.loads(event_json)

    return json.dumps({
        'target': 'newDeviceMessage',
        'arguments': [ event_item ]
    })

The IoT Hub message is passed to the function in the event argument. To send a message over SignalR Service, the function simply returns a SignalR message object and the output binding does the rest.

Receive messages over WebSockets from SignalR Service

Azure SignalR Service works with clients in many languages. Python is currently supported by an open source community library.

from signalrcore.hub_connection_builder import HubConnectionBuilder

connection = HubConnectionBuilder() \
    .with_url('https://function-app-url') \
    .build()
connection.on('newDeviceMessage', process_device_message)
connection.start()

Each time we receive a newDeviceMessage, we pass it to process_device_message() to display on the screen.

Our app uses the terminalplot library to plot our real-time data in the terminal window.

We can also use JavaScript in a browser to plot our data. In fact, we can have many different clients written in different languages that simultaneously connect to SignalR Service and receive real-time messages.

Resources

Add Real-time to your Java App with Azure SignalR Service

Anthony Chu — Fri, 11 Oct 2019 18:11:36 +0000

Azure SignalR is a fully managed service that makes it easy to add highly-scalable real-time messaging to any application using WebSockets and other protocols. SignalR Service has integrations for ASP.NET and Azure Functions. Other backend apps can use the service's RESTful HTTP API.

In this article, we'll look at the benefits of using Azure SignalR Service for real-time communication and how to integrate it with a Java Spring Boot chat application using the service's HTTP API.

Azure SignalR Service overview

While many libraries or frameworks support WebSockets, properly scaling out a real-time application is not a trivial task; it typically requires setting up Redis or other infrastructure to act as a backplane. Azure SignalR Service does all the work for managing client connections and scale-out. We can integrate with it using a simplified API.

SignalR Service uses the SignalR real-time protocol that was popularized by ASP.NET. It provides a programming model that abstracts away the underlying communication channels. Instead of managing individual WebSocket connections ourselves, we can send messages to everyone, a single user, or arbitrary groups of connections with a single API call.

SignalR also negotiates the best protocol for each connection. It prefers to use WebSockets, but if it is not available for a given connection, it will automatically fall back to server-sent events or long-polling.

There are many SignalR client SDKs for connecting to Azure SignalR Service. They're available in .NET, JavaScript/TypeScript, and Java. There are also third-party open source clients for languages like Swift and Python.

Azure SignalR Service RESTful HTTP API

Server applications, like a Java Spring app, can use an HTTP API to send messages from SignalR Service to its connected clients. There are also APIs for managing group membership; we can place users into arbitrary groups and send messages to a group of connections.

The API documentation can be found on GitHub. We'll be using these APIs in the rest of this article.

Integrating SignalR Service with Java

There are four main steps to integrating SignalR Service with an application.

Create an Azure SignalR Service instance
Add an API endpoint (/negotiate) in our Java app for SignalR clients to retrieve a token for connecting to SignalR Service
Create a connection with a SignalR client SDK (we'll be using a JavaScript app in a browser)
Send messages from our Java app

How it works

The SignalR client SDK requests a SignalR Service URL and access token using the /negotiate endpoint
The client SDK automatically uses that information establish a connection to SignalR Service
The Java app uses SignalR Service's RESTful APIs to send messages to connected clients

Create a SignalR Service instance

We can create a free instance of SignalR Service using the Azure CLI or the Azure portal. To work with the REST API, configure it to use the Serverless mode.

For more information on how to create an SignalR Service instance, check out the docs.

Add a "negotiate" endpoint

SignalR Service is secured with a key. We never want to expose this key to our clients. Instead, in our backend application, we generate a JSON web token (JWT) that is signed with this key for each client that wants to connect. A SignalR client sends a request to an HTTP endpoint we define in our application to retrieve this JWT.

This is the negotiate endpoint in our Spring Boot app. It generates a token and returns it to the caller. We can (optionally) embed a user ID into the token so we can send messages targetted to that user.

@PostMapping("/signalr/negotiate")
public SignalRConnectionInfo negotiate() {
    String hubUrl = signalRServiceBaseEndpoint + "/client/?hub=" + hubName;
    String userId = "12345"; // optional
    String accessKey = generateJwt(hubUrl, userId);
    return new SignalRConnectionInfo(hubUrl, accessKey);
}

Notice that the route ends in /negotiate. This is a requirement as it is a convention used by the SignalR clients.

The method for generating a JWT uses the Java JWT (jjwt) library and signs it with the SignalR Service key. Notice we set the audience to the hub URL.

A hub is a virtual namespace for our messages. We can have more than one hub in a single SignalR Service. For instance, we can use a hub for chat messages and another for notifications.

private String generateJwt(String audience, String userId) {
    long nowMillis = System.currentTimeMillis();
    Date now = new Date(nowMillis);

    long expMillis = nowMillis + (30 * 60 * 1000);
    Date exp = new Date(expMillis);

    byte[] apiKeySecretBytes = signalRServiceKey.getBytes(StandardCharsets.UTF_8);
    SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
    Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());

    JwtBuilder builder = Jwts.builder()
        .setAudience(audience)
        .setIssuedAt(now)
        .setExpiration(exp)
        .signWith(signingKey);

    if (userId != null) {
        builder.claim("nameid", userId);
    }

    return builder.compact();
}

Create a client connection

On our web page, we bring in the SignalR JavaScript SDK and create a connection. We add one or more event listeners that will be invoked when a message is received from the server. Lastly, we start the connection.

<script src="https://cdn.jsdelivr.net/npm/@microsoft/signalr@3.0.0/dist/browser/signalr.min.js"></script>

const connection = new signalR.HubConnectionBuilder()
  .withUrl(`/signalr`)
  .withAutomaticReconnect()
  .build()

connection.on('newMessage', function(message) {
  // do something with the message
})

connection.start()
  .then(() => data.ready = true)
  .catch(console.error)

Notice that we used the negotiate URL without the /negotiate segment. The SignalR client SDK automatically attempts the negotiation be appending /negotiate to the URL.

When we start the application and open our web page, we should see a successful connection in the browser console.

Send messages from the Java app

Now that our clients are connected to SignalR Service, we can send them messages.

Our sample is a chat app, so we have an endpoint that our frontend app will call to send messages. We use a similar method as the /negotiate endpoint to generate a JWT. This time, the JWT is used as a bearer token in our HTTP request to the service to send a message.

@PostMapping("/api/messages")
public void sendMessage(@RequestBody ChatMessage message) {
    String hubUrl = signalRServiceBaseEndpoint + "/api/v1/hubs/" + hubName;
    String accessKey = generateJwt(hubUrl, null);

    Unirest.post(hubUrl)
        .header("Content-Type", "application/json")
        .header("Authorization", "Bearer " + accessKey)
        .body(new SignalRMessage("newMessage", new Object[] { message }))
        .asEmpty();
}

And now our app should be working! To support hundreds of thousands of connections, we simply have to go into the Azure portal and increase the number of connection units with a slider.

Resources

Large-Scale Serverless Machine Learning Inference with Azure Functions

Anthony Chu — Thu, 05 Sep 2019 16:30:35 +0000

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles are published every day — that's right, every day — from community members and cloud advocates in the month of September.

Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/.

Azure Functions recently announced the general availability of their Python language support. We can use Python 3.6 and Python's large ecosystem of packages, such as TensorFlow, to build serverless functions. Today, we'll look at how we can use TensorFlow with Python Azure Functions to perform large-scale machine learning inference.

Overview

A common machine learning task is the classification of images. Image classification is a compute-intensive task that can be slow to execute. And if we need to perform classification on a stream of images, such as those coming from an IoT camera, we would need to provision a lot of infrastructure to get enough computational power to keep up with the volume and velocity of images that are being generated.

Because serverless platforms like Azure Functions automatically scale out with demand, we can use them to perform machine learning inferencing and be confident that they can keep up with high-volume workloads.

Without scaling, this is how slowly our app currently runs:

The application is pretty straightforward. Here are the key parts:

Azure Storage Queue is a low-cost but highly scalable message queue. We're create a message on the queue with the URL for each image that we want to classify.
Azure Functions is Azure's serverless functions platform. For each image URL in the queue, a Python function will run a TensorFlow model and classify the image. Azure Functions is able to scale out and parallelize this work.
Azure SignalR Service is a fully managed real-time message service that supports protocols like WebSockets. Each classification result is broadcast to a status page running in one or more browsers using SignalR Service.

Build the app

The app we're building will run an image through a TensorFlow model to predict if it contains a cat or a dog. It consists of the Azure services above. We will first build and run the function app locally.

Create the Azure services

We start by provisioning the following Azure services in the Azure portal.

Create an Azure Function app with the following parameters:
- Linux consumption plan
- Python
- New Storage account (we'll also create our queue in this account)
Create an Azure SignalR Service account with the following parameters:
- Same region as your function app
- Free tier

Create the function app

Next, we'll create a Python function app using the Azure Functions CLI. For the complete details, take a look at this Python Azure Functions machine learning tutorial.

func init --worker-runtime python

Next, we'll create a function named classifyimage that triggers whenever there's a message in our queue.

func new --template AzureQueueStorageTrigger --name classifyimage

A function is created in a folder named classifyimage.

To broadcast images using Azure SignalR Service using its Azure Functions bindings, we need to add the extension to our function app. One way to do that is by running this command.

func extensions install -p Microsoft.Azure.WebJobs.Extensions.SignalRService -v 1.0.0

We'll edit our function in a bit. But first, we need to import a TensorFlow model that we'll use to classify the images.

Import a TensorFlow model

For this app, we import a TensorFlow model that we've trained using Azure Custom Vision Service that classifies images as "cat" or "dog". For information on how to train and export your own model to recognize almost anything you can think of, check out these instructions.

The model consists of model.pb and labels.txt. There's a model here that has already been trained. We can copy the files into the folder that contains the classifyimage function.

Use the model in the function

We'll need some packages such as TensorFlow. Add them to requirements.txt and install them:

azure-functions
tensorflow
Pillow
requests

pip install --no-cache-dir -r requirements.txt

classifyimage/function.json describes the trigger, inputs, and outputs of the function. We'll update the queue name to images and add a SignalR Service output binding to the function.

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "msg",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "images",
      "connection": "AzureWebJobsStorage"
    },
    {
      "type": "signalR",
      "direction": "out",
      "name": "$return",
      "hubName": "imageclassification"
    }
  ]
}

Then we'll update the body of our function (classifyimage/__init__.py) to download the image using the URL from the queue message, run the TensorFlow model, and return the result.

import logging
import azure.functions as func
import json
from .predict import predict_image_from_url

def main(msg: func.QueueMessage) -> str:
    image_url = msg.get_body().decode('utf-8')
    results = predict_image_from_url(image_url)
    logging.info(f"{results['predictedTagName']} {image_url}")
    return json.dumps({
        'target': 'newResult',
        'arguments': [{
            'predictedTagName': results['predictedTagName'],
            'url': image_url
        }]
    })

Most of the work is done by the helper functions in predict.py which can be found here and copied into our function app. The function also returns a message that is broadcast over Azure SignalR Service. The message consists of the image URL and the prediction ("cat" or "dog").

Configure and run the app locally

We configure an Azure Functions app locally using local.settings.json. Add the connection strings to our Storage account and SignalR Service.

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "AzureWebJobsStorage": "<STORAGE_CONNECTION_STRING>",
    "AzureSignalRConnectionString": "<SIGNALR_CONNECTION_STRING>"
  }
}

Now we run the function app.

func start

Using a tool like Azure Storage Explorer, we create a queue named images in our Storage account and add a message containing an image URL. We should see our function execute.

Deploy and run the app at scale

Now that the app runs locally, it's time to deploy it to the cloud!

Run the following Azure Functions Core Tools command to deploy our app to the Azure Function app we created earlier. We're using remote build so that it brings in the proper dependencies required to run on Linux.

func azure functionapp publish <FUNCTION_APP_NAME> -b remote

We also need to configure the Storage account and SignalR Service connection strings in our function app's configuration settings.

To add a lot of image URLs to the queue, run a load generator script like this one.

The sample app also contains a status page that connects to Azure SignalR Service, receives the classification results, and displays them in real-time. To deploy this page to Azure, check out the details on the SignalR Service Serverless Developer Guide.

With the status page opened in the browser, each time a function executes and classifies an image, it'll push the result to the status page. As more and more messages are added to the queue and the Azure Functions platform detects that the queue length is growing, the function app scales out to more and more instances. The number of images classified per second will go up as the function app scales out.

Summary

In this article, we saw that Azure Functions supports Python and its many popular packages, including TensorFlow. It allows us to run machine learning inferencing tasks at a large scale. To learn more, check out these resources:

What's the big deal with IAsyncEnumerable in .NET Core 3.0?

Anthony Chu — Wed, 31 Jul 2019 22:39:18 +0000

One of the most exciting features of .NET Core 3.0 and C# 8.0 has been the addition of IAsyncEnumerable<T> (aka async streams). But what's so special about it? What can we do now that wasn't possible before?

In this article, we'll look at what challenges IAsyncEnumerable<T> is intended to solve, how to implement it in our own applications, and why IAsyncEnumerable<T> will replace Task<IEnumerable<T>> in many situations.

Check out all the new features in .NET Core 3

Life before `IAsyncEnumerable<T>`

Perhaps the best way to illustrate why IAsyncEnumerable<T> is useful is to take a look at what challenges exist without it.

Imagine we're building a data access library, and we need a method that queries a data store or API for some data. It's pretty common for that method to return Task<IEnumerable<T>>, like this:

public async Task<IEnumerable<Product>> GetAllProducts()

To implement the method, we typically perform some data access asynchronously, then return all the data when it's finished. The problem with this becomes more evident when we need to make multiple asynchronous calls to obtain the data. For example, our database or API could be returning data in pages, like this implementation that uses Azure Cosmos DB:

public async Task<IEnumerable<Product>> GetAllProducts()
{
    Container container = cosmosClient.GetContainer(DatabaseId, ContainerId);
    var iterator = container.GetItemQueryIterator<Product>("SELECT * FROM c");
    var products = new List<Product>();
    while (iterator.HasMoreResults)
    {
        foreach (var product in await iterator.ReadNextAsync())
        {
            products.Add(product);
        }
    }
    return products;
}

Notice we are paging through all the results in a while loop, instantiating all the product objects, placing them into a List<Product>, and finally we return the whole thing. This is quite inefficient, especially for larger datasets.

Maybe we can create a more efficient implementation by changing our method to return results one page at a time:

public IEnumerable<Task<IEnumerable<Product>>> GetAllProducts()
{
    Container container = cosmosClient.GetContainer(DatabaseId, ContainerId);
    var iterator = container.GetItemQueryIterator<Product>("SELECT * FROM c");
    while (iterator.HasMoreResults)
    {
        yield return iterator.ReadNextAsync().ContinueWith(t => 
        {
            return (IEnumerable<Product>)t.Result;
        });
    }
}

The caller would consume the method like this:

foreach (var productsTask in productsRepository.GetAllProducts())
{
    foreach (var product in await productsTask)
    {
        Console.WriteLine(product.Name);
    }
}

This implementation is more efficient, but the method now returns IEnumerable<Task<IEnumerable<Product>>>. As we can see in the calling code, it's not intuitive to understand how to invoke the method and process the data. More importantly, paging is an implementation detail of the data access method that the caller should know nothing about.

`IAsyncEnumerable<T>` to the rescue

What we really want to do is to retrieve data asynchronously from our database and stream results back to the caller as they become available.

In synchronous code, a method that returns IEnumerable<T> can use the yield return statement to return each piece of data to the caller as it is returned from the database.

public IEnumerable<Product> GetAllProducts()
{
    Container container = cosmosClient.GetContainer(DatabaseId, ContainerId);
    var iterator = container.GetItemQueryIterator<Product>("SELECT * FROM c");
    while (iterator.HasMoreResults)
    {
        foreach (var product in iterator.ReadNextAsync().Result)
        {
            yield return product;
        }
    }
}

However, DO NOT DO THIS! The above code turns the async database call into a blocking call and will not scale.

If only we could use yield return with asynchronous methods! That hasn't been possible... until now.

IAsyncEnumerable<T> was introduced in .NET Core 3 (.NET Standard 2.1). It exposes an enumerator that has a MoveNextAsync() method that can awaited. This means the producer can make asynchronous calls in between yielding results.

Instead of returning a Task<IEnumerable<T>>, our method can now return IAsyncEnumerable<T> and use yield return to emit data.

public async IAsyncEnumerable<Product> GetAllProducts()
{
    Container container = cosmosClient.GetContainer(DatabaseId, ContainerId);
    var iterator = container.GetItemQueryIterator<Product>("SELECT * FROM c");
    while (iterator.HasMoreResults)
    {
        foreach (var product in await iterator.ReadNextAsync())
        {
            yield return product;
        }
    }
}

To consume the results, we need to use the new await foreach() syntax available in C# 8:

await foreach (var product in productsRepository.GetAllProducts())
{
    Console.WriteLine(product);
}

This is much nicer. The method produces data as they are available. The calling code consumes the data at its own pace.

`IAsyncEnumerable<T>` and ASP.NET Core

Starting with .NET Core 3 Preview 7, ASP.NET is able to return IAsyncEnumerable<T> from an API controller action. That means we can return our method's results directly -- effectively streaming data from the database to the HTTP response.

[HttpGet]
public IAsyncEnumerable<Product> Get()
    => productsRepository.GetAllProducts();

Replacing `Task<IEnumerable<T>>` with `IAsyncEnumerable<T>`

As times goes by and the adoption .NET Core 3 and .NET Standard 2.1 grows, expect to see IAsyncEnumerable<T> to be used in places where we've typically used Task<IEnumerable<T>>.

I look forward to seeing libraries support IAsyncEnumerable<T>. Throughout this article, we've seen code like this for querying data using the Azure Cosmos DB 3.0 SDK:

var iterator = container.GetItemQueryIterator<Product>("SELECT * FROM c");
while (iterator.HasMoreResults)
{
    foreach (var product in await iterator.ReadNextAsync())
    {
        Console.WriteLine(product.Name);
    }
}

Like our earlier examples, Cosmos DB's own SDK also leaks its paging implementation detail and that makes it awkward to process query results.

To see what it could look like if GetItemQueryIterator<Product>() returned IAsyncEnumerable<T> instead, we can create an extension method on FeedIterator:

public static class FeedIteratorExtensions
{
    public static async IAsyncEnumerable<T> ToAsyncEnumerable<T>(this FeedIterator<T> iterator)
    {
        while (iterator.HasMoreResults)
        {
            foreach(var item in await iterator.ReadNextAsync())
            {
                yield return item;
            }
        }
    }
}

Now we can process our query results in a much cleaner way:

var products = container
    .GetItemQueryIterator<Product>("SELECT * FROM c")
    .ToAsyncEnumerable();
await foreach (var product in products)
{
    Console.WriteLine(product.Name);
}

Summary

IAsyncEnumerable<T> is a welcomed addition to .NET and will make for much cleaner and more efficient code in many cases. Learn more about it with these resources:

Event-Driven Serverless Containers with PowerShell Azure Functions and Azure Container Instances

Anthony Chu — Mon, 29 Apr 2019 18:44:43 +0000

Today, the Azure Functions team announced the public preview of their V2 runtime's support for PowerShell (PowerShell was previously in V1 as an experimental language).

In Azure Functions V2, PowerShell isn't just another language for writing serverless apps; it opens the door for many event-driven automation scenarios that weren't easily achieved with Azure Functions before. It uses a brand new PowerShell Core language worker built by the PowerShell team.

Using managed identities, a PowerShell Azure Function app can automatically authenticate with a system-managed Azure Active Directory identity. When combined with the Azure PowerShell module, we can write Azure Functions that can securely manage any resource in Azure.

In this article, we'll look at how we can trigger and monitor batch jobs using PowerShell Azure Functions and Azure Container Instances.

Overview (tl;dr)

What are we doing?

There are two types of workloads that have traditionally been difficult to run on serverless function platforms like Azure Functions:

Applications such as complex batch jobs that are difficult to refactor into serverless functions but can be packaged into a container
Serverless functions that need to run for longer than the maximum duration allowed by the platform (Azure Functions running in App Service and Premium plans, however, do not have limitations on duration)

With PowerShell Azure Functions, we can react to events, such as HTTP requests or queue messages, and launch our containerized job using Azure Container Instances. Azure Functions can also be used to monitor a job's progress.

How do we do it?

We'll build an Azure Function app to start and monitor containerized jobs.

Trigger a job by making an HTTP POST to /api/jobs; Azure Functions submits the job to an Azure Storage queue and returns an HTTP response with status code 202 Accepted and a location header containing a URL /api/jobs/{JobId}.
A function will be triggered by a queue message and runs the New-AzContainerGroup cmdlet to start our job.
Make HTTP GET requests to /api/jobs/{JobId} to monitor the job's progress.

The key pieces

Azure Container Instances

Azure Container Instances (ACI) is the easiest way to run containers in Azure. We can use it to run containers without worrying about provisioning infrastructure and we only pay for resources that are used.

We'll use the Azure PowerShell module in an Azure Function app to create and monitor containers in ACI.

Azure Functions

Azure Functions is Azure's flagship serverless platform. Serverless functions can be triggered by dozens of events and we can write them in C#, JavaScript/TypeScript, Java, Python, and starting today: PowerShell. (Python and PowerShell are currently in public preview.)

PowerShell Azure Functions use PowerShell Core — a newer version of PowerShell that runs on Windows, Linux, and macOS. We have access to all the modules that are supported by PowerShell Core, including the new Azure PowerShell module that makes it easy to manage resources in Azure.

Managed identities

Managed identities (formerly known as managed service identities or MSI) automatically provisions an Azure Active Directory service principal for our Azure resources, including Azure Functions.

Azure Storage queues

Every Azure Function app includes an Azure Storage account. Azure Storage has support for queues; we'll use them to asynchronously trigger an Azure Function to start an ACI to run a job.

Build the function app

Getting started

Source code

The source code for the app we're building is on GitHub.

Tools

Visual Studio Code is my favorite editor for pretty much everything. It has great support for Azure Functions as well as PowerShell (even on macOS!). To get started, install the Azure Functions Core Tools, the Azure Functions VS Code extension, and PowerShell Core.

To create a function app using the Functions Core Tools func (version 2.6.1048 and up, Functions Runtime version 2.0.12408 and up), run this command and select "PowerShell":

func init

Local configuration

For local development, Azure Functions supports placing environment variables in a local.settings.json file.

There are a couple of things that we need for this project. One is a Storage account in Azure and its connection string in a local setting named AzureWebJobsStorage.

The other is the name of the resource group (app setting ResourceGroupName) in Azure that we've already created. It will be where the container instances are created.

Azure PowerShell modules

Before we start coding, we need to ensure our app and local environment are configured for running Azure PowerShell modules.

In host.json, make sure managedDependency is enabled.

{
  "version": "2.0",
  "managedDependency": {
    "enabled": true
  }
}

And make sure there's a file named requirements.psd1 at the root of the function app that tells Azure Functions that we need the Az module to be available:

@{
    'Az' = '1.*'
}

Lastly, we need to ensure we are logged into Azure by running this command. (This is only required locally. When running in Azure, the application logs in using the app's managed identity. We'll talk about that later.)

Connect-AzAccount

Our function app will consist of three functions:

RequestJob - HTTP triggered function to queue a job and return a status URL
StartJob - Queue triggered function that creates the Azure Container Instance to run the actual job
GetJobStatus - HTTP triggered function that returns the status of a job

RequestJob function

The RequestJob function responds to an HTTP POST at /api/jobs. It generates a job ID (a GUID) and adds it as a message to an Azure Storage queue. It then returns an HTTP status of 202 Accepted and a location header containing a URL for checking the job's status.

A PowerShell function consists of a folder with the name of the function that contains two files: function.json and run.ps1.

function.json describes the trigger as well as bindings for a function. Bindings are used to read additional information from or write information to other services. We will use the Storage queue binding to output our message to a queue.

// RequestJob/function.json
{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "post"
      ],
      "route": "jobs"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "JobQueue",
      "queueName": "%JobQueueName%"
    }
  ]
}

The function is triggered by an HTTP POST request to a route named "jobs" (this will generate an HTTP route of /api/jobs). In addition, the function is configured with function level authorization, which means a correct authorization code must be provided before it will be triggered when it runs in Azure. We use this to provide a bit of security for our function so that jobs cannot be started by anonymous requests.

We're using a binding expression %JobQueueName% instead of a hardcoded value for the queue name. We can configure this value as an app setting in our function app.

# RequestJob/run.ps1
using namespace System.Net

param($Request, $TriggerMetadata)

$ContainerName = (New-Guid).ToString()
$StatusUrl = "/api/jobs/$($ContainerName)"

Push-OutputBinding -Name JobQueue -Value $ContainerName

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::Accepted
    Headers = @{
        "Location" = $StatusUrl
        "Content-type" = "application/json"
    }
    Body = $StatusUrl
})

The function generates a GUID that will be used to name the Azure Container Instance. It is also the job ID that we will use to construct our status URL.

Using the queue binding named JobQueue that we defined in function.json, the function outputs the job ID to our queue.

It also uses the HTTP output binding to return a 202 Accepted status code with a location header containing the status URL.

Our function an be invoked by making an HTTP POST request to /api/jobs?code=<function-auth-code>. The function auth code can be left empty when running locally. When running in Azure, we can use the Azure portal to open the function to locate the function's full URL, including the authorization code. Once called, the function returns a response like this:

HTTP/1.1 202 Accepted
Content-Length: 46
Content-Type: application/json; charset=utf-8
Location: /api/jobs/2b2ed845-64e1-4b08-90f2-cf485ed4bdb4
Date: Mon, 22 Apr 2019 23:24:21 GMT

/api/jobs/2b2ed845-64e1-4b08-90f2-cf485ed4bdb4

We'll build the function named GetJobStatus later that will be called when we follow the URL specified in the location header.

StartJob function

Now that we have a function that places job IDs on a queue, we'll need a function that is triggered by messages on that queue and starts the jobs.

The function.json for our function has a single queue trigger:

// StartJob/function.json
{
  "bindings": [
    {
      "name": "JobId",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "%JobQueueName%"
    }
  ]
}

The function body looks like this:

# StartJob/run.ps1
param([string] $JobId, $TriggerMetadata)

New-AzContainerGroup -ResourceGroupName $env:ResourceGroupName -Name $JobId `
    -Image alpine -OsType Linux `
    -Command "/bin/sh -c `"for i in ``seq 1 30``; do sleep 1; echo `$i; done`"" `
    -RestartPolicy Never

It receives the job ID from the queue message and uses the New-AzContainerGroup cmdlet to start a container that runs our job. For the purposes of this demo, I'll simply use the Alpine Linux container and run a loop that outputs a number every second for 30 seconds. Hopefully your applications are more interesting than this.

That's how easy it is to start a container in ACI using a PowerShell Azure Function!

GetJobStatus function

Lastly, we need an HTTP endpoint that will retrieve the container's status from ACI. This function can be anonymous as its route includes the job ID's GUID which is pretty hard to guess.

// GetJobStatus/function.json
{
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get"
      ],
      "route": "jobs/{JobId}"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

# GetJobStatus/run.ps1
using namespace System.Net

param($Request, $TriggerMetadata)

$JobId = $Request.Params.JobId

$JobStatus = Get-AzContainerGroup -ResourceGroupName $env:ResourceGroupName -Name $JobId
$JobLogs = Get-AzContainerInstanceLog -ResourceGroupName powershell-func-aci -ContainerGroupName $JobId

If ($JobStatus.State -eq "Succeeded") {
    $StatusCode = [HttpStatusCode]::OK
} ElseIf ($JobStatus.State -eq "Failed") {
    $StatusCode = [HttpStatusCode]::InternalServerError
} Else {
    $StatusCode = [HttpStatusCode]::Accepted
}

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = $StatusCode
    Headers = @{
        "Content-type" = "application/json"
    }
    Body = @{
        "state" = $JobStatus.State
        "logs" = $JobLogs
    }
})

The function pulls the job ID from the HTTP route parameters and calls Get-AzContainerGroup to retrieve the ACI's status.

In addition, it calls Get-AzContainerInstanceLog to retrieve any logs that may have been outputted by the container.

We return the status and the logs. If the container is still running, we return an HTTP status code of 202 Accepted. If it's completed we return 200 OK (succeeded) or 500 Internal Server Error (failed).

Here's an example of a call to the status URL returned by the example call to RequestJob above while the container is still running (/api/jobs/2b2ed845-64e1-4b08-90f2-cf485ed4bdb4):

HTTP/1.1 202 Accepted
Content-Length: 85
Content-Type: text/plain; charset=utf-8
Date: Mon, 22 Apr 2019 23:24:42 GMT

{
  "state": "Running",
  "logs": "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n"
}

And here's what it looked like when completed:

HTTP/1.1 200 OK
Content-Length: 154
Content-Type: text/plain; charset=utf-8
Date: Mon, 22 Apr 2019 23:25:30 GMT

{
  "state": "Succeeded",
  "logs": "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25\n26\n27\n28\n29\n30\n"
}

Deploy to Azure

Configure app settings

The first thing we need to do is create a Function app. Once the app is created, in the Azure Function app settings, configure the following settings:

FUNCTIONS_WORKER_RUNTIME - Make sure this is set to powershell
ResourceGroupName - Name of resource group where container instances will be created by the app
JobQueueName - Name of the Storage queue to hold pending jobs

Configure managed identity

Managed identity automatically provisions a service principal in Azure AD for an app. Our functions can use the identity to authenticate with and execute commands with the Azure PowerShell module.

In a PowerShell Azure Functions project, we can create a script called profile.ps1. Inside, we check if the app is running in a managed identity enabled environment and log into Azure PowerShell using that identity. This is executed during each "cold start" of the PowerShell Azure Functions worker.

# profile.ps1
if ($env:MSI_SECRET -and (Get-Module -ListAvailable Az.Accounts)) {
    Connect-AzAccount -Identity
}

In order for our function app to be able to create container instances in the resource group we specified in the settings, we have to grant the app's managed identity contributor access to the resource group.

Deploy with Functions Core Tools

Once the app is configured, we can deploy our app by running the follow Functions Core Tools command:

func azure functionapp publish <name of the function app>

Test the app

Once the app is deployed, open it in the Azure portal and select the RequestJob function. Click on Get function URL to retrieve the function's URL including the authorization code.

Use an app like Postman to make a POST request to the function to start a job. The function will respond with a status URL. Make a GET request to that URL to retrieve the job's current status and logs.

Resources

Translating Speech in Real-Time with Your Browser and the Cloud

Anthony Chu — Mon, 08 Apr 2019 15:57:34 +0000

When we do a live presentation — whether online or in person — there are often folks in the audience who are not comfortable with the language we're speaking or they have difficulty hearing us. Microsoft created Presentation Translator to solve this problem in PowerPoint by sending real-time translated captions to audience members' devices.

In this article, we'll look at how (with not too many lines of code) we can build a similar app that runs in the browser. It will transcribe and translate speech using the browser's microphone and broadcast the results to other browsers in real-time. And because we are using serverless and fully managed services on Azure, it can scale to support thousands of audience members. Best of all, these services all have generous free tiers so we can get started without paying for anything!

Overview

The app consists of two projects:

A Vue.js app that is our main interface. It uses the Microsoft Azure Cognitive Services Speech SDK to listen to the device's microphone and perform real-time speech-to-text and translations.
An Azure Functions app providing serverless HTTP APIs that the user interface will call to broadcast translated captions to connected devices using Azure SignalR Service.

Speech SDK for Cognitive Services

Most of the heavy-lifting required to listen to the microphone from the browser and call Cognitive Speech Services to retrieve transcriptions and translations in real-time is done by the service's JavaScript SDK.

The SDK requires a Speech Services key. You can create a free account (up to 5 hours of speech-to-text and translation per month) and view its keys by running the following Azure CLI commands:

az cognitiveservices account create -n $SPEECH_SERVICE_NAME -g $RESOURCE_GROUP_NAME --kind SpeechServices --sku F0 -l westus
az cognitiveservices account keys list -n $SPEECH_SERVICE_NAME -g $RESOURCE_GROUP_NAME

You can also create a free Speech Services account using the Azure portal using this link (select F0 for the free tier).

Azure SignalR Service

Azure SignalR Service is a fully managed real-time messaging platform that supports WebSockets. We'll use it in combination with Azure Functions to broadcast translated captions from the presenter's browser to each audience member's browser. SignalR Service can scale up to support hundreds of thousands of simultaneous connections.

SignalR Service has a free tier. To create an instance and obtain its connection string, use the following Azure CLI commands:

az signalr create -n $SIGNALR_NAME -g $RESOURCE_GROUP_NAME --sku Free_DS2 -l westus
az signalr key list -n $SIGNALR_NAME -g $RESOURCE_GROUP_NAME

You can also use the Azure portal to create one by using this link.

Speech-to-text and translation in the browser

Cognitive Service's Speech SDK is really easy to use. To get started, we'll pull it into our Vue app:

npm install microsoft-cognitiveservices-speech-sdk

Then we just need to initialize and start it:

// listen to the device's microphone
const audioConfig = AudioConfig.fromDefaultMicrophoneInput()
// use the key and region created for the Speech Services account
const speechConfig = SpeechTranslationConfig.fromSubscription(options.key, options.region)

// configure the language to listen for (e.g., 'en-US')
speechConfig.speechRecognitionLanguage = options.fromLanguage
// add one or more languages to translate to
for (const lang of options.toLanguages) {
  speechConfig.addTargetLanguage(lang)
}

this._recognizer = new TranslationRecognizer(speechConfig, audioConfig)

// assign callback when text is recognized ('recognizing' is a partial result)
this._recognizer.recognizing = this._recognizer.recognized = recognizerCallback.bind(this)
// start the recognizer
this._recognizer.startContinuousRecognitionAsync()

And that's it! The recognizerCallback method will be invoked whenever text has been recognized. It is passed an event argument with a translations property that contains all the translations we asked for. For example, we can obtain the French translation with e.translations.get('fr').

Broadcast captions to other clients

Now that we can obtain captions and translations thanks to the Cognitive Services Speech SDK, we need to broadcast that information to all viewers who are connected to SignalR Service via WebSocket so that they can display captions in real-time.

First, we'll create an Azure Function that our UI can call whenever new text is recognized. It's a basic HTTP function that uses an Azure SignalR Service output binding to send messages.

The output binding is configured in function.json. It takes a SignalR message object returned by the function and sends it to all clients connected to a SignalR Service hub named captions.

{
  "disabled": false,
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "signalR",
      "name": "$return",
      "hubName": "captions",
      "direction": "out"
    }
  ]
}

The function simply takes the incoming payload, which includes translations in all available languages, and relays it to clients using SignalR Service. (Sending every language to every client is quite inefficient; we'll improve on this later with SignalR groups.)

module.exports = async (context, req) => ({
    target: 'newCaption',
    arguments: [req.body]
});

Back in our Vue app, we bring in the SignalR SDK:

npm install @aspnet/signalr

Note that even though this package is under the @aspnet org on npm, it's the JavaScript client for SignalR. It may move to a different org later to make it easier to find.

When an audience member decides to join the captioning session and our Vue component is mounted, we'll start a connection to SignalR Service.

async mounted() {
  this.connection = new signalR.HubConnectionBuilder()
    .withUrl(`${constants.apiBaseUrl}/api`)
    .build()
  this.connection.on('newCaption', onNewCaption.bind(this))
  await this.connection.start()
  console.log('connection started')

  function onNewCaption(caption) {
    // add the caption for the selected language to the view model
    // Vue updates the screen
  }
}

Whenever a newCaption event arrives, the onNewCaption callback function is invoked. We pick out the caption that matches the viewer's selected language and add it to the view model. Vue does the rest and updates the screen with the new caption.

We also add some code to disconnect from SignalR Service when the Vue component is destroyed (e.g, when the user navigates away from the view).

async beforeDestroy() {
  if (this.connection) {
    await this.connection.stop()
    console.log('connection stopped')
  }
}

And that's pretty much the whole app! It captures speech from the microphone, translates it to multiple languages, and broadcasts the translations in real-time to thousands of people.

Increase efficiency with SignalR groups

There's a flaw in the app we've built so far: each viewer receives captions in every available language but they only need the one they've selected. Sometimes captions are sent multiple times per second, so sending every language to every client uses a lot of unnecessary bandwidth. We can see this by inspecting the WebSocket traffic:

To solve problems like this, SignalR Service has a concept called "groups". Groups allow the application to place users into arbitrary groups. Instead of broadcasting messages to everyone who is connected, we can target messages to a specific group. In our case, we'll treat each instance of the Vue app as a "user", and we will place each of them into a single group based on their selected language.

Instead of sending a single message containing every language to everyone, we will send smaller, targeted messages that each contains only a single language. Each message is sent to the group of users that have selected to receive captions in that language.

Add a unique client ID

We can generate a unique ID that represents the Vue instance when the app starts up. The first step to using groups is for the app to authenticate to SignalR Service using that identifier as the user ID. We achieve this by modifying our negotiate Azure Function. The SignalR client calls this function to retrieve an access token that it will use to connect to the service. So far, we've been using anonymous tokens.

We'll start by changing the route of the negotiate function to include the user ID. We then use the user ID passed in the route as the user ID in the SignalRConnectionInfo input binding. The binding generates a SignalR Service token that is authenticated to that user.

{
  "disabled": false,
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "post"
      ],
      "route": "{userId}/negotiate"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "signalRConnectionInfo",
      "direction": "in",
      "userId": "{userId}",
      "name": "connectionInfo",
      "hubName": "captions"
    }
  ]
}

There are no changes required in the actual function itself.

Next, we need to change our Vue app to pass the ID in the route (clientId is the unique ID generated by this instance of our app):

this.connection = new signalR.HubConnectionBuilder()
  .withUrl(`${constants.apiBaseUrl}/api/${this.clientId}`)
  .build()

The SignalR client will append /negotiate to the end of the URL and call our function with the user ID.

Add the client to a group

Now that each client connects to SignalR Service with a unique user ID, we'll need a way to add a user ID to the group that represents the client's selected language.

We can do this by creating an Azure Function named selectLanguage that our app will call to add itself to a group. Like the function that sends messages to SignalR Service, this function also uses the SignalR output binding. Instead of passing SignalR messages to the output binding, we'll pass group action objects that are used to add and remove users to and from groups.

const constants = require('../common/constants');

module.exports = async function (context, req) {
    const { languageCode, userId } = req.body;
    const signalRGroupActions =
        constants.languageCodes.map(lc => ({
            userId: userId,
            groupName: lc,
            action: (lc === languageCode) ? 'add' : 'remove'
        }));
    context.bindings.signalRGroupActions = signalRGroupActions;
};

The function is invoked with a languageCode and a userId in the body. We'll output a SignalR group action for each language that our application supports — setting an action of add for the language we have chosen to subscribe to, and remove for all the remaining languages. This ensures that any existing subscriptions are deleted.

Lastly, we need to modify our Vue app to call the selectLanguage function when our component is created. We do this by creating a watch on the language code that will call the function whenever the user updates its value. In addition, we'll set the immediate property of the watch to true so that it will call the function immediately when the watch is initially created.

methods: {
  async updateLanguageSubscription(languageCode) {
    await axios.post(`${constants.apiBaseUrl}/api/selectlanguage`, {
      languageCode,
      userId: this.clientId
    })
  }
},
watch: {
  toLanguageCode: {
    handler() {
      return this.updateLanguageSubscription(this.toLanguageCode)
    },
    immediate: true
  }
},

Send messages to groups

The last thing we have to do is modify our Azure Function that broadcasts the captions to split each message into one message per language and send each to its corresponding group. To send a message to a group of clients instead of broadcasting it to all clients, add a groupName property (set to the language code) to the SignalR message:

module.exports = async function (context, req) {
    const captions = req.body;

    const languageCaptions = Object.keys(captions.languages).map(captionLanguage => ({
        language: captionLanguage,
        offset: captions.offset,
        text: captions.languages[captionLanguage]
    }));

    const signalRMessages = languageCaptions.map(lc => ({
        target: 'newCaption',
        groupName: lc.language,
        arguments: [ lc ]
    }));

    return signalRMessages;
};

Now when we run the app, it still works the same as it did before, but if we inspect the SignalR traffic over the WebSocket connection, each caption only contains a single language.

Next steps

Check out the source code on GitHub
Deploy the app — more details in the SignalR Service serverless programming guide
Explore Azure Speech Services and the SignalR Service bindings for Azure Functions

Thoughts? Questions? Leave a comment below or find me on Twitter.

Build Real-time Serverless Apps with Azure SignalR Service

Anthony Chu — Wed, 06 Mar 2019 18:03:42 +0000

Today, Microsoft announced the general availability of the Azure SignalR Service bindings for Azure Functions. The bindings allow Azure Functions to integrate seamlessly with SignalR Service to broadcast real-time messages at large scale over WebSockets.

We'll take a look at how to build a browser-based, collaborative drawing app using HTML and JavaScript. Multiple people can open the app in their own browser and draw on the canvas. Changes are synchronized in real-time using Azure Functions and SignalR Service.

Java language support in Azure Functions has also recently become generally available. In this article, we'll be writing our functions in Java, but the SignalR Service bindings also work with other languages supported by Azure Functions. Check out the GitHub repo for source code in Java, C#, and JavaScript.

Overview

There are three major components of the app: the drawing canvas, the Azure Function app, and Azure SignalR Service.

The canvas is a simple JavaScript app that runs in the browser. When the app starts up, it retrieves the SignalR Service connection endpoint and access token from an Azure Function named "negotiate".
The app connects to SignalR Service and a real-time channel is established. It's usually a WebSocket connection, but SignalR will automatically fallback to other transports if WebSocket is not available for a given connection.
When lines are drawn on the canvas, the app sends a series of strokes to an Azure Function named "draw".
The draw Azure Function uses SignalR Service to broadcast the series of strokes to all connected clients.

Create an Azure SignalR Service instance

Azure SignalR Service is a fully managed real-time messaging platform that our app will use to broadcast messages. We can create a free instance of the service in the Azure portal, or we can run the following Azure CLI command.

az signalr create -n $SIGNALR_NAME -g $GROUP_NAME --sku Free_DS2 -l westus

After the instance is created, we'll need to get the connection string that will be used by the function app.

az signalr key list -n $SIGNALR_NAME -g $GROUP_NAME

Build the Azure Function app

The Azure Function app consists of two key functions. The first is a negotiate function that returns the SignalR Service connection information. The second is a draw function that is called whenever lines are drawn on any canvas; it will broadcast the lines to the other canvases.

If you haven't worked with Azure Functions before, check out their quickstarts.

negotiate function

This HTTP triggered function uses the SignalRConnectionInfoInput binding to generate the access token and endpoint information for the client. The binding generates this information using the connection string.

@FunctionName("negotiate")
public SignalRConnectionInfo negotiate(
    @HttpTrigger(
      name = "req",
      methods = { HttpMethod.POST },
      authLevel = AuthorizationLevel.ANONYMOUS) HttpRequestMessage<Optional<String>> req,
    @SignalRConnectionInfoInput(
      name = "connectionInfo",
      hubName = "serverlessdraw") SignalRConnectionInfo connectionInfo) {
  return connectionInfo;
}

draw function

The draw HTTP triggered function uses the SignalROutput binding to broadcast the strokes that were drawn on a canvas to all canvases that are currently connected to SignalR Service.

It simply relays the contents of the HTTP request body to SignalR Service.

@FunctionName("draw")
public void draw(
    @HttpTrigger(
      name = "req",
      methods = { HttpMethod.POST },
      authLevel = AuthorizationLevel.ANONYMOUS) HttpRequestMessage<StrokeCollection> req,
    @SignalROutput(
      name = "signalRMessage",
      hubName = "serverlessdraw") OutputBinding<SignalRMessage> signalRMessage) {

  StrokeCollection strokeCollection = req.getBody();
  SignalRMessage msg = new SignalRMessage("newStrokes", strokeCollection);
  signalRMessage.setValue(msg);
}

Create the drawing canvas

The canvas is a surprisingly simple browser-based JavaScript app that uses an HTML canvas. You can watch me build the first version of it on my Twitch stream.

SignalR Service connection

The first thing we do when the canvas app starts is connect to SignalR Service. We can reference the SignalR JavaScript client using a CDN.

<script src="https://cdn.jsdelivr.net/npm/@aspnet/signalr@1.1.2/dist/browser/signalr.js"></script>

Then we can use the client to create a connection to SignalR Service. By convention, the SignalR client will append /negotiate at the end of the URL to discover the connection negotiation endpoint, so we'll leave that part off of our function's URL when we initialize the HubConnectionBuilder.

var connection = new signalR.HubConnectionBuilder()
  .withUrl(`${apiBaseUrl}/api`) // function URL minus /negotiate
  .build()

// set up event listeners
connection.on('newStrokes', drawStrokes)
connection.on('clearCanvas', clearCanvas)

connection.start()
  .then(() => console.log('connected'))

Between configuring the connection and starting it, we set up a couple of event listeners. When an event arrives from SignalR Service that matches one of those names, the event handler will be called. Here's what the clearCanvas function looks like:

function clearCanvas() {
  ctx.clearRect(0, 0, canvas.width, canvas.height)
}

The drawing canvas

The main canvas is (you guessed it) a single <canvas> tag:

<canvas id="draw-canvas" height="500" width="800"></canvas>

The main JavaScript function is named mouseMove. It is called when each stroke is drawn. We figure out the start and end of the line, and draw it on the canvas. Then we add the stroke to an array so that we can collect a few strokes together and send them off in a batch.

function mouseMove(ev) {

  // 🌟 math happens here

  drawStroke(start, end, colorButton.value)
  unsentStrokes.push({
    start: start,
    end: end,
    color: colorButton.value
  })
}

Every 250 milliseconds or so, we post our batch of strokes to our draw Azure Function.

setInterval(function () {
  if (unsentStrokes.length) {
    axios.post(`${apiBaseUrl}/api/draw`, {
      sender: clientId,
      strokes: unsentStrokes
    })
    unsentStrokes = []
  }
}, 250)

The draw function will use SignalR Service to raise the newStrokes event in each running instance of our app. This invokes a function named drawStrokes to draw the stroke.

Here's what the finished product looks like:

Check out the GitHub repo for the source code of the function app in Java, JavaScript, and C#.

Forem: Anthony Chu

Overcoming Serverless challenges with Durable Functions

Rendering PDFs with Razor Templates and PuppeteerSharp in Azure Functions

Overview

Create an ASP.NET Core Razor Pages app

Use PuppeteerSharp in C# Azure Functions

Reference and start the Razor app from Azure Functions

Render the Razor page as a PDF

Deploy to Azure

Resources

Running headless Chromium in Azure Functions with Puppeteer and Playwright

Browser automation with Puppeteer and Playwright

Azure Functions support for headless Chromium

Use Puppeteer and Playwright in Azure Functions

Puppeteer

Playwright

Deploy to Azure

Configuring VS Code for remote build

Creating a Linux Consumption function app

Configuring Chromium download location (Playwright only)

Publishing the app

Resources

Authenticate Blazor WebAssembly with Azure Static Web Apps

Overview

Basic setup

Install NuGet package

Register services

Update App.razor

User authentication

Adding login links

Accessing user's identity

Running locally

Access control

Conditionally showing page in navigation

Preventing page from displaying to anonymous users

Blocking access to API

Conclusion

Resources

Azure Functions and App Service Authentication with Auth0 and other OpenID Connect providers

Overview

Create an app in Auth0

Create an authentication config file

Add a client secret app setting

Enable file-based auth configuration

Test it out

Resources

End-to-End Serverless Real-Time IoT with Python

Send telemetry to Azure IoT Hub using MQTT

Relay messages from IoT Hub to Azure SignalR Service with Azure Functions

Receive messages over WebSockets from SignalR Service

Resources

Add Real-time to your Java App with Azure SignalR Service

Azure SignalR Service overview

Azure SignalR Service RESTful HTTP API

Integrating SignalR Service with Java

How it works

Create a SignalR Service instance

Add a "negotiate" endpoint

Create a client connection

Send messages from the Java app

Resources

Large-Scale Serverless Machine Learning Inference with Azure Functions

Overview

Build the app

Create the Azure services

Create the function app

Import a TensorFlow model

Use the model in the function

Configure and run the app locally

Deploy and run the app at scale

Summary

What's the big deal with IAsyncEnumerable in .NET Core 3.0?

Life before IAsyncEnumerable<T>

IAsyncEnumerable<T> to the rescue

IAsyncEnumerable<T> and ASP.NET Core

Replacing Task<IEnumerable<T>> with IAsyncEnumerable<T>

Summary

Event-Driven Serverless Containers with PowerShell Azure Functions and Azure Container Instances

Overview (tl;dr)

What are we doing?

Life before `IAsyncEnumerable<T>`

`IAsyncEnumerable<T>` to the rescue

`IAsyncEnumerable<T>` and ASP.NET Core

Replacing `Task<IEnumerable<T>>` with `IAsyncEnumerable<T>`