Blazor
Kostenloses Whitepaper: ASP.NET Core Blazor WebAssembly
Christian Weyer hat zum Thema „ASP.NET Core Blazor WebAssembly – das SPA-Framework für .NET-Entwickler?“ ein Whitepaper erstellt, in dem er alles Wissenswerte zusammengefasst hat.
Melden Sie sich kostenlos zu unserem Newsletter an, um das Whitepaper per E-Mail zu erhalten.
Klassische Web-Anwendungen bis hin zu Single-Page Applications
Die ersten Web-Anwendungen, wie sie bereits in der Mitte 90er Jahren aufkamen, waren ausschließlich Server-rendered. Mittels eines Interpreters wie beispielsweise Perl oder PHP wurden die Anfragen des Webbrowsers ausgewertet, und eine neue Antwort-Seite erzeugt, die dann zum Browser geschickt wurde. Für den Browser, und damit den Nutzer, war also jede Operation in der Web-Anwendung mit einem vollständigen neuen Laden der Seite verbunden.
Blazor WebAssembly
Blazor WebAssembly adaptiert sehr stark die Architekturüberlegungen und Denkmuster der etablierten Single-Page Application Frameworks. Der Unterschied von Blazor WebAssembly zu einer JavaScript-basierten SPA besteht hauptsächlich darin, dass tatsächlich unser .NET Code im Browser ausgeführt wird. Dies geschieht unter Verwendung des WebAssembly-Standards in einem mehrstufigen Prozess.
Hinweis: Der Browser unseres Benutzers muss dazu echte .NET IL Assemblies, also klassische binäre .dll-Dateien, von unserem Webserver herunterladen. Das ist allerdings etwas, das viele Firewalls, insbesondere die etwas restriktiveren im Unternehmensumfeld, nur zu gerne aktiv unterbinden: Der Download von ausführbaren Dateien kann daher blockiert sein – und damit ist unsere Blazor WebAssembly Anwendung nicht ausführbar.
Mittels der PWA-Erweiterungen (Progressive Web Apps) für Blazor WebAssembly ist es, wie auch bei reinen JavaScript-basierten SPAs, möglich, die Anwendung durch das Bereitstellen eines sogenannten Manifestes und eines Service Workers im Browser zwischenzuspeichern und damit eine vollständig offline fähige Anwendung zu erstellen. Natürlich stehen uns in der JavaScript-Runtime des Browsers auch nur Browser-APIs zur Verfügung. Von hier aus können z.B. keine normalen Socket-Verbindungen aufgebaut werden, wie es z.B. für einen Datenbankzugriff notwendig ist.
Blazor Server
Wie man auf dem folgenden Screenshot sieht, wird auch hier wieder ein JavaScript geladen, aber dann wird die SignalR-Verbindung aufgebaut und die Anwendung läuft.
Und ja: Die Ähnlichkeit dieses Konzeptes mit Mainframes (Server) und Terminals bzw. Thin-Clients als Eingabe-Ausgabe-Schnittstelle (Browser) sind nicht von der Hand zu weisen.
Was bedeutet dieser Unterschied?
- Es wird eine permanente Verbindung zwischen Server und Browser benötigt. Blazor Server Anwendungen sind grundsätzlich nicht offline-fähig.
- Wir unterliegen keinen API-Limits des Browser mehr: Zugriffe unseres Codes auf dem Server auf spezielle Schnittstellen und externe Hardware fallen deutlich leichter (z.B. Industriemaschinen, Scanner, Sensoren, Bus-Systeme, direkte Datenbankzugriffe etc.). Auch, weil nun sehr leicht externe Bibliotheken dafür eingebunden werden können.
- Auf dem Server kann unsere Anwendung mit anderen APIs über beliebige Protokolle kommunizieren. Eine aufwendige Anpassung an das Web oder Serialisierung/Deserialisierung über HTTP(S) können entfallen.
Da die Anwendung auf dem Server ausgeführt wird, und nur die reine HTML-Oberfläche ohne Logik im Browser, benötigen wir jedoch eine permanente, stabile Netzwerk-Verbindung zwischen unserem Browser und dem Webserver. Idealerweise haben wir hier auch eine möglichst niedrige Latenz, damit unsere Eingaben möglichst schnell zum Server kommen, bearbeitet werden und die Antwort wieder zurückkommt. Haben wir eine große Latenz, fühlt sich die Anwendung extrem langsam an und der Nutzer muss für jede einzelne Aktion an der Oberfläche lange warten bis die Anwendung reagiert. Der Benutzer sollte also im besten Fall möglichst nahe am Server verortet und möglichst latenzfrei (LAN statt WAN) angebunden sein.
Der Ansatz, die Anwendung auf dem Server laufen zu lassen, bedeutet auch, dass der Server für alle gleichzeitigen Nutzer die entsprechenden Ressourcen bereithalten muss. Das sind zum einen Netzwerkanbindung und -bandbreite, zum anderen aber vor allem ausreichend Arbeitsspeicher, um den Zustand aller gleichzeitigen Verbindungen zu halten und zum dritten ausreichend CPU-Kapazitäten, falls die Anwendung rechenintensive Aufgaben für jeden Nutzer ausführen muss. Im Gegenzug wird hier der Client entlastet und so kann unsere Webanwendung auch auf eher schwachen Rechnern wie z.B. Chromebooks oder Tablets wie z.B. den günstigen Amazon Fire-Geräten effizient genutzt werden.
Der zweite Punkt eröffnet uns dabei sehr interessante Möglichkeiten: Wir können beispielsweise direkt aus unserer Webanwendung heraus auf Datenbanken zugreifen, ohne erst eine Web-API zwischen dem Web-Frontend und dem Server-Backend entwerfen und implementieren zu müssen. Dies erspart viel Arbeit. Genauso können wir z.B. schon existierende Bibliotheken weiterverwenden, auch wenn wir diese nicht nach WebAssembly kompilieren können.
Wann nehme ich was?
Blazor WebAssembly ist geeignet, wenn unsere Anwendung auch offline funktionieren soll. Auch wenn wir starke Clients haben, können wir die Last dorthin verschieben und von den Browser-APIs profitieren. Dies ermöglicht uns, die Anwendung als echte Progressive Web-App zu erstellen. Wir müssen jedoch bedenken, dass vor allem Firewalls von Firmen hier etwas übereifrig sein und unsere Anwendung blockieren könnten.
Blazor Server ist dann eine Option, wenn man sicherstellen kann, dass alle Clients eine stabile Netzwerkverbindung mit geringer Latenz zum Server haben. Wenn unsere Anwendung ressourcenintensiv ist, kann diese so auch für günstige Client-Geräte nutzbar gemacht werden, indem wir zentral auf dem Server die entsprechenden Ressourcen bereitstellen. Wenn unsere Anwendung vom Server aus unmittelbar mit speziellem Code, APIs oder Bibliotheken kommunizieren muss, und diese nicht als Web-APIs bereitstehen bzw. nur sehr aufwändig bereitzustellen sind, kann Blazor Server auch den Aufwand eine Oberfläche zu Web-ifizieren reduzieren. In solchen Fällen bietet Blazor Server die Möglichkeit, diesen Code mit weniger Aufwand in einer neuen, Web-basierten Anwendung wiederzuverwenden. Allerdings ist dies genau so bei ASP.NET MVC oder Razor-Pages Anwendungen der Fall.
Auch die dritte Option, beides zu kombinieren, möchte ich an dieser Stelle nicht verschweigen: Man kann z.B. eine Anwendung primär als Blazor WebAssembly bereitstellen, aber für die Benutzer, die z.B. durch eine Firewall am Download der Assemblies gehindert werden, die gleiche Anwendung als Fallback auch in der Server-Version betreiben.
Zuletzt rufen wir uns wieder ins Gedächtnis, dass Blazor in beiden Fällen einfach Blazor ist. Wir können also eine (UI-)Komponentenbibliothek und auch die Businesslogik so erstellen, dass sie unabhängig von den jeweils speziellen APIs ist. Diesen Code können wir dann in Anwendungen verwenden, die wir mit Blazor WebAssembly auf die Geräte schieben – und zeitgleich auch in anderen Blazor Server-Anwendungen wiederverwenden.
Blazor @ Thinktecture
Oftmals werden wir gefragt, welche Technologie aus unserer Sicht „die richtige“ sei. Das hängt selbstverständlich immer von allen Gesamtumständen ab und es gibt darauf keine universelle Antwort. Dennoch haben wir eine Meinung dazu:
Grundsätzlich – komplett unabhängig von Technologieen – stellt sich bei Web-basierten Anwendungen heutzutage immer auch noch die Frage, ob es eine SPA sein muss, oder ob eine klassische, vom Server gerenderte, Webanwendung nicht doch ausreicht. SPAs kommen dabei zwangsläufig immer mit einer etwas höheren Komplexität daher: Wir bauen eine Fat-Client Anwendung mit eigener Zustandshaltung und diesen müssen wir irgendwie mit dem Zustand auf dem Server synchron halten. Wir müssen die Browser-Navigation mit einbeziehen (Routing), wir sind auf Browser-APIs beschränkt. Diese höhere Komplexität bietet uns aber bei Progressive Web Apps (PWA) eben auch die Möglichkeit, eine vollständig offlinefähige und damit „richtige“ Mobile-App zu bauen – und dabei alles aus der Plattform Web herauszuholen was sie uns anbietet, ohne plattformspezifischen Code schreiben zu müssen. Generell sagen wir daher: Eine SPA ergibt genau dann Sinn, wenn wir sie auch wirklich benötigen. Brauchen wir die Optionen die uns eine SPA bietet nicht, spricht eher vieles für klassische Server-Rendered Anwendungen, denn es ist in der Tat viel einfacher.
Und was bedeutet das für Blazor?
Blazor Server ist, wie der Name schon sagt, eine Server-Technologie. Wenn unsere Webanwendung also sowieso schon auf dem Server leben muss und offline gar nicht funktionieren kann, dann stellen wir uns natürlich die Frage, warum man die Anwendung dann nicht gleich als eine normale Server-Rendered Anwendung, z.B. mit ASP.NET Core MVC oder Razor Pages erstellt? Welchen Mehrwert würde uns Blazor Server bieten, um den Mehraufwand und die höhere Komplexität einer SPA-Technologie zu rechtfertigen? Wir finden: Eigentlich keinen.
Blazor WebAssembly ist hingegen ein richtiges SPA-Framework das es uns ermöglicht echte Browser-basierte Anwendungen zu bauen die auch in der Lage sind, alle SPA-Vorteile voll auszuspielen.
Fazit
Blazor WebAssembly wird im Web-Browser ausgeführt, wohingegen eine Blazor Server-Anwendung auf dem Server „lebt“. Blazor Server ist mit seinem Ansatz eher mit einer Anwendung die via „Remote Desktop“ bzw. „X11 fürs Web“ bereitgestellt wird zu vergleichen. Der Ansatz von Blazor WebAssembly erlaubt es, eine richtige, potentiell auch rein offlinefähige, Single-Page Application zu erstellen. Blazor-Komponenten können, sofern sie der richtigen entkoppelten Architektur folgen, ohne Änderungen in beiden Anwendungsmodellen verwendet werden.
Bei der Entscheidung, welche dieser Technologien die richtige für ein Projekt ist, muss man unter anderem die Punkte der gegebenen Netzwerkumgebung, das Lastverhalten und die Verfügbarkeit bzw. die Abhängigkeiten von Browser- bzw. Serverspezifischen APIs berücksichtigen.
Blazor Server kann dabei ein Sprungbrett hin zur echten SPA sein oder ein Fallback falls es technische Schwierigkeiten mit dem Deployment-Modell von WebAssembly gibt. Falls man allerdings keine SPA benötigt, sind Server-Rendered Anwendungungen wie Razor Pages oder ASP.NET Core MVC genau so gute Alternativen zu Blazor Server.
![Asynchrone Operationen: Blazor WebAssembly für Angular-Entwickler – Teil 5 [Screencast]](https://www.thinktecture.com/storage/2021/04/favicon-150x150.jpg)