© Zoom Photo Graphic Stock/shutterstock.com, © S&S Media
Teil 1: Blazor Server ist mit ASP.NET Core 3.0 erschienen

Der erste Blazor-Streich


Viele .NET-Entwickler warten seit der Erstankündigung im März 2018 sehnsüchtig auf Blazor, das .NET-basierte Web-Framework zur Entwicklung von Single Page Applications. Mit Server-side Blazor (alias Blazor Server) ist nun in .NET Core 3.0 bereits eine Form von Blazor erschienen, die sich aber nur für kleine bis mittlere Nutzerzahlen eignet.

Bei der Erstankündigung im März 2018 hatte Microsoft zunächst nur Blazor auf Basis von WebAssembly im Webbrowser vorgestellt. Hier laufen C#-Code und .NET-Assemblies direkt im Browser – wie einst bei Silverlight. Am 10. August 2018 in Preview 0.5 folgte dann Server-side Blazor, bei dem der gleiche Programmcode auch auf dem Webserver laufen konnte. Dieses Feature wurde unter dem Stichwort „Out of Process Execution“ entwickelt [1]. Danach bezeichnete Microsoft zur Abgrenzung das ursprüngliche WebAssembly-basierte Architekturmodell als Client-side Blazor.

In der Folgezeit hat Microsoft nicht nur mit der Technik, sondern auch dem Namen der beiden Blazor-Varianten experimentiert. Zunächst sollte die serverseitige Ausführung mit „ASP.NET Core Razor Components“ einen komplett anderen Namen erhalten. Im April 2019 revidierte Microsoft das aber, was auch weise war, denn Razor Components war den vorhandenen Konzepten wie Razor Views (in ASP.NET Core MVC), Razor Pages (eine Alternative zu ASP.NET Core MVC) und Razor Class Libraries (zur Kapselung von Razor Views und Razor Pages) namentlich zu ähnlich. Der letzte Namensstand aus dem Juli 2019, der auch für die am 23. September 2019 erschienene RTM-Version der Serverausführung gilt, ist: Die Serverausführung heißt Blazor Server, die Clientausführung Blazor WebAssembly.

Was ist Blazor Server?

Blazor Server ist stark erklärungsbedürftig, denn obwohl es auf dem Webserver läuft (wie der Namen besagt), macht es dennoch keine vollständigen Seitenrundgänge wie die klassischen Server-side Rendering (SSR) Frameworks alias Multi Page Application (MPA) Frameworks, wie z. B. ASP.NET MVC, ASP.NET Razor Pages, JSP oder PHP. Mit Blazor Server entsteht vielmehr eine Single Page Application (SPA): Der Benutzer sieht im Browser nur einen URL und es flackert auch zwischendurch nicht durch den Wechsel ganzer HTML-Seiten, denn es ändern sich bei SPA-Interaktionen nur immer einzelne Seitenteile.

Wer nun an das Feature „Server-side-(Pre-)Rendering“ denkt, das es in einigen JavaScript-basierten SPA-Web-Frameworks gibt (vgl. Angular Universal [2], React [3], Vue.js [4], Next.js [5] und Aurelia [6]), erfasst damit die Fähigkeiten von Blazor Server nicht ganz. Blazor Server dient nicht nur dem Vorrendern einiger statischer Seiten auf dem Webserver, um dem Benutzer das erste Seitenerlebnis schneller zu präsentieren und währenddessen ein SPA Framework in den Browser zu laden, sondern mit Blazor Server kann ein Entwickler tatsächlich eine komplette SPA-Webanwendung erstellen und hat bei Bedarf (mit etwas eingestreutem JavaScript/TypeScript) auch vollen Zugriff auf alle Browser-APIs.

Es stellt sich die Frage, wie das möglich ist. Abbildung 1 veranschaulicht die Architektur und Funktionsweise von Blazor Server. Auf der Serverseite läuft bei Blazor Server eine Razor Component, die neben dem obligatorischen Razor-Template-Teil (HTML-Tags mit eingestreutem C#) auch noch eine Code-behind-Datei (in C#) umfassen kann. Mit dem Razor-Template erzeugt der Softwareentwickler zwar eine komplette Webseite, diese wird aber nur beim ersten Aufruf einmalig als Ganzes zum Browser gesendet. Zusätzlich wird beim ersten Laden eine JavaScript-Bibliothek von Microsoft (blazor.server.js) zum Browser geschickt.

schwichtenberg_blazor1_1.tif_fmt1.jpgAbb. 1: So funktioniert Blazor Server

Blazor merkt sich auf dem Webserver das initial zum Browser gesendete HTML in Form eines virtuellen Abbilds des Browserinhalts, also des Document Object Models (DOM). Dieses Virtual DOM wird im Folgenden dafür verwendet, jegliche DOM-Änderungen festzustellen und nur noch diese zum Webbrowser zu übertragen. Die Bibliothek blazor.server.js ist clientseitig dafür zuständig, diese Änderungsmitteilungen in das echte DOM des Webbrowsers einzubauen.

Ebenso ist es Aufgabe von blazor.server.js, die Interaktionen des Benutzers mit dem Browser (Tastatureingaben und Mausklicks) zum Webserver zu übertragen und dort für Ereignisse in der Razor Component zu sorgen. Nach Abarbeitung des Ereignisses erfolgt eine Übertragung der resultierenden DOM-Änderungen zum Client. Die Übertragungen zwischen Webbrowser und Webserver erfolgt in einem von Microsoft definierten Format via ASP.NET Core SignalR über eine WebSocket-Verbindung. Microsoft nennt das neue Protokoll BlazorPack [7]. Damit der Benutzer ein gutes Erlebnis mit der Anwendung hat, muss laut Microsoft die Netzwerklatenz unter 250 Millisekunden liegen [8].

Eine Blazor-Server-Anwendung ist folglich nicht offlinefähig und aufgrund des serverseitigen Virtual DOM, dass es für jeden angeschlossenen Browser gibt, auch nicht gut skalierbar. Microsoft hat dokumentiert, dass für jeden angeschlossenen Browser schon bei einer Hello-World-Anwendung 250 KB RAM im Server gebraucht werden [9]. Für echte Anwendung sei der RAM-Bedarf jeweils zu messen. Dass Microsoft das nicht genauer vorhersagen kann, ist nachvollziehbar, denn der RAM-Bedarf ist von vielen Faktoren abhängig, insbesondere natürlich von der Komplexität der Benutzeroberflächen und der Menge der im Zustand der Komponente gehaltenen Daten.

Der RAM-Bedarf ist aber kein grundsätzliches K.-o.-Kriterium für Blazor Server. Es gibt genug Webwendungen auf dieser Welt, die eine begrenzte Benutzeranzahl haben und für die das SPA-light-Konzept der Blazor-Server-Apps geeignet ist. Zudem hat man als Softwareentwickler bei Blazor Server durch die Programmiertechnik erheblichen Einfluss auf die Höhe des RAM-Bedarfs.

Blazor im Vergleich zu seinen Kollegen

Abbildung 2 zeigt alle fünf nun in ASP. NET Core verfügbaren Architekturalternativen im Vergleich:

schwichtenberg_blazor1_2.tif_fmt1.jpgAbb. 2: ASP.NET Core bietet mittlerweile fünf Architekturalternativen
  1. Ganz oben sieht man die Model-View-Controller-Architektur (MVC), die es seit Version 1.0 (2016) in ASP.NET Core gibt und die es zuvor schon im klassischen ASP.NET gab. Der Controller auf dem Server füttert die View mit Daten. Die View erzeugt mit der Razor-Template-Syntax eine HTML-Seite, die als Ganzes zum Webbrowser übertragen wird. Der Browser schickt Daten per U...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang