Blazor Server – eine unterschätzte Technologie?
.NET Entwickler hoffen schon lange auf das frimelige JavaScript verzichten zu können. Bringt Blazor Server die Lösung? Hans Peter Bornhauser erklärt, wie die neue Technologie funktioniert und sinnvoll eingesetzt wird.
Ursprünglich ein experimentelles Projekt bei Microsoft war Blazor zunächst einmal das Versprechen, in Form von WebAssemblies Single Page Applications (SPA) für den Browser nur mit C# zu schreiben. Zumindest .NET Entwickler hoffen schon lange auf das frimelige JavaScript verzichten zu können und performante Applikationen für Web-Frontends zu schreiben. WebAssemblies versprechen dank Vorabkompilierung bessere Performance und geringere Bandbreite und werden von allen aktuellen Browsern unterstützt.
Die grosse Enttäuschung
Gross war dann die Enttäuschung als Microsoft im Herbst 2019 zunächst mit Blazor Server auf den Markt kam. Man sah Blazor Server lediglich als Übergangslösung bis zum Release von Blazor WebAssembly im Mai 2020. Schliesslich erfordert Blazor Server eine stehende Verbindung – Offline Applikationen als Progressive Web App (PWA) sind undenkbar – und pro aktivem Client werden auf dem Server dauernd rund 85 kByte Speicher belegt. An Skalierbarkeit ist nicht zu denken.
Inzwischen ist Blazor WebAssembly verfügbar und wird stetig weiterentwickelt. Die Ahead of Time (AoT) Compilation wurde zwar auf .NET 6 verschoben, dennoch hat .NET 5 die Performance für WebAssemblies in vielen Bereichen verdoppelt oder verdreifacht. Ist das also das Ende von Blazor Server?
Funktionsweise von Blazor Server
Schauen wir uns dazu zunächst die Funktionsweise von Blazor Server an: Die .NET Applikation läuft auf dem Server und arbeitet mit einem virtuellen DOM (Document Object Model, der Inhalt der Webseite). Für die Applikation sieht es also so aus, als ob sie mit einem lokalen Display arbeitet und sie hat zudem Zugriff auf alle Server-Ressourcen wie Datenbanken, Filesystem oder beliebige andere Hardwarekomponenten.
Blazor sendet alle Änderungen des virtuellen DOM unmittelbar über eine SignalR WebSocket Verbindung an den Browser. Der Browser übermittelt jeden Event über die gleiche Verbindung an den Server zurück.
Die initiale Ladezeit einer Blazor Server Applikation ist sehr kurz, da nicht die ganze Applikation, sondern nur die erste HTML-Seite an den Browser übertragen wird. Die weiteren Updates des DOM sind relativ kleine WebSocket Messages.
Wo gibt es eine sinnvolle Anwendung dafür? Überall dort, wo stabile Verbindungen, eine begrenzte Zahl von Clients und der Zugriff auf Server-Ressourcen eine grosse Rolle spielen.
Ein sinnvoller Einsatz
Der Wunsch, Maschinensteuerungen internetfähig zu machen entsteht immer häufiger. Leistungsfähige Controller sind günstig und häufig kommt Linux als Betriebssystem zum Einsatz. Da liegt es nahe, ein Web-Frontend zu bauen, auf das der Anwender sowohl vom internen Display als auch von einem abgesetzten Terminal (Tablet, Mobile, Backoffice-PC) zugreifen kann. Responsive Web Design bietet dazu die ideale Lösung. Ein lokaler Bediener fokussiert sich auf die Steuerung der Maschine, während ein Anwender im Backoffice an Produktionsdaten und Statistiken interessiert ist.
Das Look-and-Feel der Applikation entspricht einer SPA. Anders als beim klassischen Request-Response Modell sind Updates des Servers einfach an den Client zu übertragen. Zudem muss sich der vermutlich auf Embedded Systeme spezialisierte Entwickler nur am Rande in Webtechnologien einarbeiten und kann auf komplexe JavaScript-Frameworks wie Angular oder React verzichten.
Blazor Server ist für diesen Fall ideal geeignet. .NET Core läuft auf Linux und mit Kestrel steht ein leistungsfähiger Webserver für das Hosting der Blazor Applikation bereit.
Der Begriff Blazor kommt übrigens von Browser + Razor = Blazor.