Building a serverless Blazor Application: Eine Chat-App in Blazor

Home » Flurfunk » Building a serverless Blazor Application: Eine Chat-App in Blazor

Building a serverless Blazor Application: Eine Chat-App in Blazor

15. Juni 2020

Im ersten Artikel dieser Serie habe ich gezeigt, wie ASP.NET Blazor-Anwendungen mithilfe von Microsoft Azure schnell und kostengünstig serverlos gehostet werden können. Die dort beschriebene Anwendung war allerdings recht simpel und bot keine echte Funktionalität. Das wollen wir in diesem Artikel ändern.

Zum Verständnis der Begriffe ASP.NET-Blazor und Serverless sei auf den eingangs erwähnten ersten Artikel verwiesen. Auch im Weiteren geht es vorrangig um Blazor Client (WebAssembly)-Anwendungen. Die Code-Beispiele funktionieren wahrscheinlich auch für Blazor Server-Projekte, allerdings gelten dort z.T. andere Konzepte. Dort brauchen wir beispielsweise keine zusätzlichen serverlosen Komponenten zum Zugriff auf unser Backend, da die Anwendung bereits auf einem Server läuft.

Das Beispiel

Um nicht nur abstrakt über theoretische Konzepte zu sprechen, wollen wir im Folgenden eine einfache Chat-Anwendung entwickeln. Diese soll folgende Funktionalität bieten:

Der Anwender kann sich mit einem Nutzernamen anmelden
Der Anwender kann anderen Nutzern Nachrichten senden
Der Anwender kann Nachrichten von anderen Nutzern ansehen
Die Nachrichten werden online gespeichert

Im ersten Schritt werden wir folgende Vereinfachungen treffen:

1. Die Anmeldung erfolgt nur mit Nutzernamen (ohne Passwort)

Security ist ein wichtiges, aber auch komplexes Thema, das den Rahmen dieses Artikels sprengen würde. Deshalb kann sich erst einmal jeder Anwender als jeder Nutzer ausgeben. Eventuell werde ich die Anwendung in einem vierten Artikel um eine echte Nutzer-Authentifizierung erweitern. Aktuell gibt es zudem noch einen Fehler in der entsprechenden Bibliothek von Microsoft.

2. Die Nachrichten werden nicht zum Empfänger gepushed.

Die Erweiterung um Echtzeit-Funktionalität ist eigentlich der Hauptschwerpunkt einer Chat-Anwendung, führt für diesen Artikel allerdings zu weit. Das Thema werden wir uns im dritten Part dieser Serie in Ruhe ansehen.

Hinweis: Der Code der fertigen Anwendung steht auf GitHub bereit. Dieser enthält allerdings bereits die Erweiterungen für die Echtzeit-Funktionalität, die wir in Artikel 3 betrachten werden.

Erstellung der Chat-App

.
Architektur

Da wir in diesem Beispiel mehr als ein Projekt verwenden, bietet es sich an, eine Visual Studio Solution anzulegen. Alternativ kann aber auch mit dem Visual Studio Code gearbeitet werden. Insgesamt brauchen wir drei Projekte:

1. Eine .NET Standard Class Library, in der gemeinsam genutzte Klassen abgelegt werden. Wird im Folgenden als „Shared“ bezeichnet.

2. Das Blazor Client-Projekt. Dieses kann über Visual Studio oder über die Kommandozeile erstellt werden, wie im ersten Artikel beschrieben. In beiden Fällen ist darauf zu achten, dass eine WebAssembly-Anwendung erstellt und dabei nicht „ASP.NET Core hosted“ ausgewählt wird.

3. Ein Azure Function-Projekt. Dieses kann ebenfalls über Visual Studio oder Visual Studio Code erstellt werden. Sinnvoll ist es hier, die .NET-Core-Runtime auszuwählen, um die Class-Library aus Punkt 1 referenzieren zu können.

In der „Shared“-Bibliothek benötigen wir zunächst nur eine einzige Klasse, „Message.cs“:


public class Message
{
    public string SourceUserName { get; set; }
    public string TargetUserName { get; set; }
    public string Content { get; set; }
    public DateTime DateTime { get; set; }
}

Diese repräsentiert eine Nachricht zwischen zwei Usern und besteht aus Zeitstempel und Inhalt. Dank ASP.NET Blazor können wir dieselbe Klasse sowohl im Frontend als auch im Backend verwenden und brauchen keine Entsprechung in JavaScript zu entwickeln und zu pflegen.

Das Backend

Schauen wir uns nun zunächst das Backend an. Wir wollen eine serverlose Architektur entwickeln, weshalb wir auf Azure Functions zurückgreifen. Zum Speichern der übertragenen Nachrichten brauchen wir zusätzlich noch einen Datenspeicher. Am komfortabelsten ist hier die Azure CosmosDB, da wir die Nachrichten einfach als semi-strukturierte Dokumente ablegen können, ohne zuerst relationale Tabellen zu definieren.

Wir erstellen also zunächst eine Function App und eine CosmosDB in Azure. Hier können jeweils die einfachsten Optionen ausgewählt werden, wichtig sind nur der passende Runtime stack (.NET Core) und die Einstellung „Consumption (Serverless)“ als Plan bei der Function App sowie „Core (SQL)“ als API bei der CosmosDB.

Im erstellten CosmosDB Account erstellen wir dann eine neue Datenbank „Chat“ und darin einen Container „Messages“. Der Datenbank-Durchsatz kann auf minimal 400 RU/s herabgesetzt werden. Das Indexing kann entweder auf Automatic gelassen oder zur Kostenersparnis deaktiviert werden. Als Partition Key genügt für das Beispiel eine der Properties (z.B. „/TargetUserName“). Sinnvoller wäre an dieser Stelle eine Message-ID als Partition Key und jeweils ein Range-Index auf den beiden UserName-Properties, nach denen wir filtern werden. Mehr zum Thema Partitioning und Indexing in der CosmosDB unter den jeweiligen Links.

(Hinweis: Die CosmosDB kann im Vergleich zu den übrigen verwendeten Services (Function App, Storage Account, CDN) spürbar teurer werden. Eine einfachere Alternative ist der Azure Table Storage. Für die Konzepte in diesem Artikel bietet der Table Storage vergleichbare SDKs und Schnittstellen. Er bietet aber nicht die Funktionalität für die Real-Time-Updates in Artikel 3.)

Schauen wir uns nun die Azure Functions an. Insgesamt brauchen wir zwei Funktionen innerhalb unserer Function App, eine zum Senden und eine zum Abfragen von Nachrichten:

[FunctionName("GetMessages")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = "GetMessages/{userName}")] HttpRequest req,
    [CosmosDB(
        databaseName: "Chat",
        collectionName: "Messages",
        ConnectionStringSetting = "CosmosDBConnection",
        SqlQuery = "SELECT * FROM Messages m WHERE m.SourceUserName = {userName} OR m.TargetUserName = {userName}")
    ] IEnumerable<Message> messages,
    ILogger log)
{
    log.LogInformation($"{messages.Count()} items loaded");
    return new OkObjectResult(messages);
}

Die Funktion GetMessages erwartet als URL-Parameter einen Nutzernamen und lädt dann aus der eben erstellten CosmosDB-Datenbank alle Nachrichten von oder zu diesem Nutzer. Der Datenbank-Zugriff erfolgt dabei direkt über ein CosmosDB-Binding, wir brauchen hier also keine eigenen API-Calls durchzuführen. Dadurch wird der Rumpf der Funktion sehr simpel.

Mehr Informationen zu Azure Function Trigger und Bindings gibt es in diesem Flurfunkartikel von Alexander Jung.

Die Klasse „Message“ entspricht der aus unserer Shared Classlibrary, die wir vom Funktion-Projekt aus referenzieren müssen. Zusätzlich brauchen wir das NuGet-Package Microsoft.Azure.WebJobs.Extensions.CosmosDB.

[FunctionName("SendMessage")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequest req,
    [CosmosDB(databaseName: "Chat", collectionName: "Messages", ConnectionStringSetting = "CosmosDBConnection")] IAsyncCollector<Message> messagesOut,
    ILogger log)
{
    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    var data = JsonConvert.DeserializeObject<Message>(requestBody);

    if (data != null)
        await messagesOut.AddAsync(data.Value);

    return new OkResult();
}

Die zweite Funktion zum Senden von Nachrichten sieht ein wenig komplexer aus. Hier erwarten wir gesendete Message als JSON-Objekt im Body des HTTP-POST-Aufrufs. Das CosmosDB-Binding dient dieses Mal als Output, in den wir das deserialisierte Objekt stecken können. Auch hier müssen wir uns dank des Bindings nicht mit den API-Calls der CosmosDB beschäftigen. Einzig das Umwandeln des JSONs in ein Objekt ist nötig. Azure Functions referenzieren standardmäßig Newtonsoft.Json, das wir hier verwenden.

Jetzt kann die Funktion App schon gepublished werden. Im Azure Portal müssen wir dann noch die nötigen Settings (unter <Function App> -> Configuration) setzen. Aktuell ist das nur der Wert für „CosmosDBConnection“, den wir im CosmosDB-Bindung verwenden. Den dafür nötigen Connection-String bekommen wir im Portal unter <CosmosDB> -> Keys.

Außerdem sollten wir unter <Function App> -> „Platform features“ -> CORS die URL unserer Blazor-App hinzufügen. Für Anwendungen, die über „dotnet run“ gestartet werden, ist das http://localhost:5000 bzw. https://localhost:5001. Visual Studio verwendet andere Ports. Außerdem muss der Haken bei „Enable Access-Control-Allow-Credentials” gesetzt werden. Wenn die App wie in Artikel 1 beschrieben auf einem Storage Account und/oder über von Azure CDN-Endpunkt gehostet wird, sollte die entsprechende URL hier ebenfalls angegeben werden.

Zuletzt können wir in der Übersicht der Function-App auf eine der Funktionen klicken und dort „Manage“ auswählen. Von hier benötigen wir später einen Function- bzw. Host-Key.

Der Client

In unserem Blazor Client-Projekt können wir erstmal überflüssige Funktionalität aus der Beispielanwendung entfernen. Dazu gehören die Pages „Counter“ und „FetchData“, die „SurveyPromt“ im Ordner „Shared“ und das Verzeichnis „sample-data“ unter „wwwroot“.

Als erste Ergänzung legen wir dann eine Model-Klasse namens „User“ an:

User.cs

using System.ComponentModel.DataAnnotations;
…
public class User
{
    [Required]
    [StringLength(15, ErrorMessage="Name too long")]
    public string UserName { get; set; }
}

In diesem Beispiel enthält die Klasse nur den Namen eines Nutzers, sinnvollerweise könnte sie aber auch Informationen wie die E-Mail-Adresse oder die interne ID speichern. Die Attribute dienen zur Steuerung der Eingabe im folgenden Abschnitt:

Index.razor

Als nächstes nehmen wir uns die Index.razor-Datei vor und ersetzen den bisherigen Code durch folgenden:

@page "/"
@using BlazorChatApp.Models
@using BlazorChatApp.Services
@inject ChatService Service

<h1>Hello, @(_sourceUser.UserName ?? "please sign in")!</h1>

Welcome to your Blazor chat app.


@if(!_loggedIn)
{
<h3>Login:</h3>
<EditForm Model="@_sourceUser" OnSubmit="@HandleUserSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <InputText id="user-name" @bind-Value="_sourceUser.UserName" />

    <button type="submit">Login</button>
</EditForm>
}
else
{
<h3>Chat with user:</h3>
<EditForm Model="@_newTargetUser" OnSubmit=@HandleTargetSubmit>
    <DataAnnotationsValidator />
    <ValidationSummary />

    <InputText id="user-name" @bind-Value="_newTargetUser.UserName" />

    <button type="submit">Create</button>
</EditForm>
}


@code {
    private User _sourceUser = new User();
    private User _newTargetUser = new User();
    private bool _loggedIn = false;

    protected override void OnInitialized()
    {
        if(Service.User != null)
        {
            _sourceUser = Service.User;
            _loggedIn = true;
        }
    }

    private async Task HandleUserSubmit()
    {
        if(!string.IsNullOrWhiteSpace(_sourceUser.UserName))
        {
            _loggedIn = true;
            await Service.SignInUser(_sourceUser);
        }
    }

    private void HandleTargetSubmit()
    {
        Service.AddTargetUser(_newTargetUser.UserName);
        _newTargetUser = new User();
    }
}

Diese Seite erfüllt zwei Aufgaben: Solange kein Benutzer angemeldet ist, fragt sie den Anwender nach seinem Nutzernamen. Alternativ, wenn ein Benutzer angemeldet ist, erlaubt sie das Hinzufügen neuer Chat-Partner über deren Nutzernamen.

Dazu bietet sie zwei EditForm-Elemente, mit denen die Namen für zwei User-Objekte abgefragt werden. Diese entsprechen HTML-Forms, verfügen allerdings über eingebaute Validierungs-Unterstützung, die über die zuvor besprochenen Attribute der Model-Properties gesteuert wird. In diesem Beispiel wird automatisch ein Fehler angezeigt und der Login verweigert, wenn mehr als 15 Zeichen eingegeben werden.

Im Fall einer erfolgreichen Eingabe werden die Methoden einer ChatService-Klasse aufgerufen, die am Beginn der Datei injiziert wird. Diese enthält die eigentliche Funktionalität unserer Chat-Anwendung und wird uns im Folgenden beschäftigen:

Die ChatService-Klasse

Zunächst brauchen wir ein paar Felder und Properties:

public class ChatService
{
    private readonly HttpClient Http;
    private readonly IConfiguration Configuration;

    public User User {get; private set;}

    private IDictionary<string, List<Message>> _messages;
    public IEnumerable<string> TargetUsers => _messages.Keys;

    public IEnumerable<Message> GetMessages(string user) => _messages[user];

Die Klasse Message ist die aus unserer Class Library, die wir dazu referenzieren müssen. IConfiguration stammt aus dem Package Microsoft.Extensions.Configuration, das bereits referenziert sein sollte. Mehr zum Thema Konfiguration in Blazor später noch. Der HttpClient stammt aus System.Net.Http und ist in Blazor standardmäßig über Dependency Injection verfügbar.

Ansonsten hält der Service den gerade angemeldeten User und eine Sammlung von Nachrichten, indiziert nach dem jeweiligen Chat-Partner. Die Liste der bekannten Chat-Partner ist entsprechend die Liste aller Keys im Nachrichten-Dictionary.

Im Constructor initialisieren wir die Felder und konfigurieren den HttpClient:

public ChatService(HttpClient client, IConfiguration configuration)
{
    Configuration = configuration;
    Http = client;
    Http.BaseAddress = new System.Uri(Configuration["API_Base_URL"]);
    Http.DefaultRequestHeaders.Add("x-functions-key", Configuration["API_Host_Key"]);

    _messages = new Dictionary<string, List<Message>>();
}

Anstelle der Konfigurations-Werte können hier zu Testzwecken auch feste String-Werte eingetragen werden. Die BaseAddress ist dabei die URL der Function App (https://<yourapp>.azurewebsites.net), der Host Key stammt von der oben beschriebenen Management-Seite der Function App. Da der Client alle Funktionen der Functions App aufruft, ist ein Host Key hier sinnvoller als ein individueller Function Key für jede der Funktionen. (Achtung: Niemals den „Master“-Key verwenden, am besten einen eigenen Host Key für die Anwendung generieren!)

Des Weiteren brauchen wir noch EventHandler, um die Views der Anwendung zu informieren, wenn sich etwas geändert hat, zum Beispiel ein neuer User oder eine neue Nachricht dazugekommen ist:

public delegate void UserChangeEventHandler();
public event UserChangeEventHandler UsersChanged;

public delegate void NewMessageEventHandler(string user);
public event NewMessageEventHandler NewMessage;

Jetzt können wir die beiden Hauptmethoden anlegen. Zum einen wollen wir einen Nutzer „anmelden“ und all seine Nachrichten herunterladen können:

public async Task SignInUser(User newUser) {
    User = newUser;
    await RetrieveMessages();
}

private async Task RetrieveMessages() {
    if(User != null)
    {
        var messages = await Http.GetJsonAsync<IEnumerable<Message>>($"{Configuration["API_URL_PART_GetMessages"]}/{User.UserName}");
        if(messages != null)
        {
            Console.WriteLine($"Received {messages.Count()} messages");
            _messages = messages
                .GroupBy(m => m.TargetUserName != User.UserName ? m.TargetUserName : m.SourceUserName)
                .ToDictionary(g => g.Key, g => g.OrderBy(e => e.DateTime).ToList());

            UsersChanged?.Invoke();
        }
    }
}

Der neue User wird einfach als aktueller User gesetzt. Dann wird die zuvor definierte Azure Function „GetMessages“ aufgerufen. Diese liefert zum aktuellen UserName alle gespeicherten Nachrichten zurück. Dank der GetJsonAsync-Erweiterung erhalten wir die Antwort direkt als Liste von „Message“-Objekten – derselben Klasse, in der wir sie auf der anderen Seite ausgeliefert haben.

Zum anderen soll der User Nachrichten verschicken können:

public async Task SendMessage(string targetUser, string content)
{
    if(User != null) {
        var message = new Message {
            SourceUserName = User.UserName,
            TargetUserName = targetUser,
            Content = content,
            DateTime = DateTime.Now
        };

        await Http.PostJsonAsync(Configuration["API_URL_PART_SendMessages"], message);

        _messages[targetUser].Add(message);
        NewMessage?.Invoke(targetUser);
    }
}

Hier erzeugen wir ein neues Objekt der „Message“-Klasse und senden es in einem Post-Aufruf an die „SendMessages“-Function auf Azure. Dann wird die neue Nachricht zu den bisher bekannten hinzugefügt und der passende EventHandler aufgerufen.

Ansonsten brauchen wir noch eine Möglichkeit, einen neuen Chat-Partner anzulegen:

public void AddTargetUser(string newTargetUser)
{
    if(!_messages.ContainsKey(newTargetUser))
    {
        _messages.Add(newTargetUser, new List<Message>());
        UsersChanged?.Invoke();
    }
}

Jetzt fehlen nur noch ein paar View-Anpassungen:

Views

Zuvor erweitern wir die _Imports.razor-Datei um die Configuration, damit wir das Objekt überall verfügbar haben:

   1: @using Microsoft.Extensions.Configuration
   2: @inject IConfiguration Configuration

Dann zu den eigentlichen Views.

Zuerst bauen wir das NavMenu um. Statt der gelöschten Unterseiten Counter und FetchData wollen wir jetzt eine Liste aller bekannten Chat-Partner anzeigen und auf deren Nachrichtenverlauf verweisen:

@using BlazorChatApp.Services
@inject ChatService Service
@implements IDisposable

<div class="top-row pl-4 navbar navbar-dark">
    <a class="navbar-brand" href="">@Configuration["Title"]</a>
    <button class="navbar-toggler" @onclick="ToggleNavMenu">
        <span class="navbar-toggler-icon"></span>
    </button>
</div>

<div class="@NavMenuCssClass" @onclick="ToggleNavMenu">
    <ul class="nav flex-column">
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="" Match="NavLinkMatch.All">
                <span class="oi oi-plus" aria-hidden="true"></span> Add User
            </NavLink>
        </li>
        @foreach(var userName in Service.TargetUsers)
        {
            var href = $"/chat/{userName}";
            <NavLink class="nav-link" href="@href" Match="NavLinkMatch.All">
                <span aria-hidden="true"></span> @userName
            </NavLink>
        }
    </ul>
</div>

@code {
    private bool collapseNavMenu = true;
    private string NavMenuCssClass => collapseNavMenu ? "collapse" : null;
    private void ToggleNavMenu()
    {
        collapseNavMenu = !collapseNavMenu;
    }

    protected override void OnInitialized()
    {
        Service.UsersChanged += Refresh;
    }

    void IDisposable.Dispose()
    {
        Service.UsersChanged -= Refresh;
    }

    private void Refresh() => StateHasChanged();
}

Der wichtige Teil ist die Foreach-Schleife, die einen Navigations-Eintrag für jeden Chat-Partner anlegt. Im @Code-Teil registriert sich die View für den UsersChanged-Eventhandler, damit beim Bekanntwerden eines neuen Users die Liste neu generiert wird.

Dann legen wir noch eine neue Page an (Chat.razor), die den Nachrichtenverlauf mit einem Chat-Partner repräsentiert:

@page "/chat/{UserName}"
@using BlazorChatApp.Services
@inject ChatService Service
@implements IDisposable

<h1>Chat with @UserName</h1>

@foreach(var message in Service.GetMessages(UserName))
{
    var directionClass = message.TargetUserName == UserName ? "send" : "received";

    <div class="chat-message @(directionClass)">
        <span class="datetime">@message.DateTime.ToString()</span>
        <p class="message-content">@message.Content</p>
    </div>
}

<input placeholder="Message" @bind="CurrentMessage" />
<button class="btn btn-primary" @onclick="SendMessage">Send</button>

@code {
    [Parameter]
    public string UserName {get;set;} = "";

    private string CurrentMessage {get;set;}

    protected override void OnInitialized()
    {
        Service.NewMessage += HandleNewMessage;
    }

    void IDisposable.Dispose()
    {
        Service.NewMessage -= HandleNewMessage;
    }
    private async Task SendMessage()
    {
        if(!string.IsNullOrWhiteSpace(CurrentMessage))
        {
            await Service.SendMessage(UserName, CurrentMessage);
            CurrentMessage = "";
        }
    }

    private void HandleNewMessage(string user)
    {
        if(user == UserName)
        {
            StateHasChanged(); // Löst Neuberechnung der Komponente aus
        }
    }
}

Der Name des Chat-Partners wird hier als URL-Parameter übergeben („/chat/{UserName}“). Es wird der bisherige Nachrichtenverlauf dargestellt und ein Input-Feld zum Eingeben einer neuen Nachricht angeboten. Ansonsten registriert sich die View auf das NewMessage-Event und aktualisiert entsprechend die Ansicht, wenn eine neue Nachricht eintrifft. Dies geschieht auch beim Senden einer Nachricht, weshalb es keinen „StateHasChanged“-Aufruf in „SendMessage“ braucht.

Es fehlt noch ein letzter Schritt:

Program.cs

In der Main-Methode müssen wir zunächst einmal unsere ChatService-Klasse registrieren:

   1: builder.Services.AddSingleton<ChatService>();

Außerdem brauchen wir die Configuration.

Hier stoßen wir auf einen wesentlichen Unterschied zwischen Blazor Server und Blazor Client/WebAssembly. In Blazor Server Anwendungen können wir die Configuration mit normalen ASP.NET Core-Mitteln konfigurieren (z.B. über eine appsettings.json). Dort liegt das entsprechende File sicher auf dem Server, wo es nur von der Anwendung, nicht aber von außen erreichbar ist.

Bei einer Blazor Client-Anwendung wird jedoch der gesamte Anwendungs-Code auf den Rechner des Aufrufers heruntergeladen und dort ausgeführt. Eine auf die gleiche Weise zur Verfügung gestellte Config-Datei wäre also für den Nutzer sichtbar. Connection-Strings zu Datenbanken oder andere Credentials dürfen deshalb niemals in der Konfiguration einer Blazor Client-Anwendung auftauchen. Diese Systeme sollten immer hinter einer API (z.B. einer Azure Function) versteckt werden.

Trotzdem gibt es Informationen, die in einer Client-Konfiguration abgelegt werden müssen, z.B. für unterschiedliche Umgebungen. Um das zu erreichen haben wir grundsätzlich zwei Möglichkeiten:

1. Bereitstellen der Config als statisches File. Wir legen die Konfigurations-Datei direkt neben den Daten unserer Anwendung ab (z.B. unter wwwroot/config). Das macht es einfach, die Konfig auf Backend-Seite auszutauschen, dafür ist sie direkt im Traffic der Seite sichtbar und problemlos von außen lesbar. Hier dürften also bestenfalls sehr allgemeine Daten wie der umgebungsabhängige Titel der Anwendung abgespeichert werden.

2. Bereitstellen der Config als embedded resource. Dazu im Visual Studio die Datei auswählen -> Properties -> unter BuildAction „embedded resource“ wählen. Das sorgt dafür, dass die Datei mit in das Anwendungs-Assembly gepackt wird. Dort ist sie etwas sicherer als auf dem Webserver, allerdings keinesfalls unerreichbar für ausreichend versierte Nutzer. Für Daten wie die URL und die Function-Keys unserer Azure Function ist dies vermutlich trotzdem der beste Weg. Die eigentliche Absicherung der Function gegen unbefugte Zugriffe sollte ohnehin nicht allein auf dem Key, sondern auf einer individuellen Nutzer-Authentifizierung basieren!

Das in Variante 2 eingebettete File kann wie folgt in der Main-Funktion geladen werden:

var assembly = Assembly.GetExecutingAssembly();
var resource = assembly.GetName().Name + ".appsettings.json";
var stream = assembly.GetManifestResourceStream(resource);

var config = new ConfigurationBuilder()
        .AddJsonStream(stream)
        .Build();

builder.Configuration.AddConfiguration(config);

(Das ist die Quintessenz aus den Blogs https://remibou.github.io/Configuring-a-Blazor-app/ sowie https://developingdane.com/configuration-in-blazor-client/ … Eine offizielle Anleitung von Microsoft zur Konfiguration von Blazor Client habe ich nicht gefunden).

Hinweis1: Die Erweiterungs-Methode AddJsonStream stammt aus dem Package Microsoft.Extensions.Configuration.Json.

Wer unnötige DLLs sparen möchte, bekommt ein äquivalentes Ergebnis mit:

var config = await System.Text.Json.JsonSerializer
    .DeserializeAsync<Dictionary<string, string>>(stream);
builder
    .Configuration
    .AddInMemoryCollection(config)
    .Build();

(System.Text.Json wird ohnehin referenziert.) Diese Option lässt sich aber deutlich schlechter um z.B. Sections erweitern als die obere.

Hinweis2: Der direkte Aufruf builder.Configuration.AddJsonStream(stream) funktioniert aktuell(?) nicht! Es muss der Umweg über new ConfigurationBuilder genommen werden. Dieses Verhalten kann in einer künftigen Version behoben sein.

Fazit

Mithilfe von Azure Function App und Azure CosmosDB haben wir mit wenigen Schritten eine grundlegend funktionsfähige, serverlose Chat-App entwickelt, in der Nutzer persistente Nachrichten miteinander austauschen können:

(Diese Abbildung erfordert noch einige hier nicht aufgeführte CSS-Anpassungen)

Insbesondere die Interaktion mit der API aus Blazor heraus ist sehr einfach und die Ergebnisse können dank der .NET Eventhandler schnell auf die Views übertragen werden. Einer der größten Vorteile von Blazor gegenüber JavaScript-Frameworks macht sich aber in der Verwendung der „Shared“-ClassLibrary bemerkbar, durch die Client und Backend direkt mithilfe derselben geteilten Klassen kommunizieren können.

Bisher funktioniert der Nachrichtenaustausch allerdings nicht synchron. Der Empfänger erhält Chat-Nachrichten erst nach einem Reload der Anwendung. Wer mag, kann zur Übung noch einen Refresh-Button einbauen. Alternativ werde ich im dritten Teil der Artikelserie beschreiben, wie wir mit Azure SignalR Service eine serverlose Echtzeit-Funktionalität in die Anwendung integrieren können.

autor

Michel Richter

Senior eXpert