Am Puls von Microsoft

Entwicklertagebuch MyLife #3: Was’n Blazor WASM?

Entwicklertagebuch MyLife #3: Was’n Blazor WASM?

In den ersten beiden Teilen dieser Reihe haben wir uns mit der Generierung der Datenstruktur unseres digitalen Lebens beschäftigt. Nun ist es am der Zeit, uns an die Anzeige dieser zu machen. Als erstes hierfür versuchen wir uns an Blazor WebAssembly, kurz Blazor WASM.

Für alle, denen diese Artikelreihe noch unbekannt ist – das habt ihr bislang verpasst, könnt euch aber natürlich nachträglich einlesen:

Klarstellung: Ich bin Anfänger

Wie all unsere Basteleien ist auch MyLife.NET (GitHub Repository) zum Lernen, Experimentieren und Fehler machen da. Vor allem in diesem Artikel, wo es um Webentwicklung geht, möchte ich hierauf noch einmal explizit hinweisen. In Dingen wie JavaScript, CSS oder gar auch bei einfachem HTML bin ich blutiger Anfänger, welcher bisher um diese Themen einen großen Bogen machte – einfach aus Desinteresse an der Thematik. Ich bin mehr in Bereichen wie Mobile- oder Server-Entwicklung zu Hause. Dennoch möchte ich die Entwicklungszeit von MyLife.NET nutzen, um etwas hier rein zu schnuppern. Für Verbesserungsvorschläge bin ich auf GitHub immer offen und ich freue mich von euch lernen zu können.

Was ist Blazor WASM?

Als erstes klären wir, was genau Microsoft .NET Blazor ist. Blazor ist ein ASP.NET Webframework zum Erstellen reaktiver Webanwendungen. Diese Webseiten setzen sich aus sogenannten und seit vielen Jahren bekannten Razor-Komponenten zusammen. Diese Komponenten können entweder einzelne Bestandteile einer Seite sein wie ein Textfeld, aber auch ganze Seiten mit URL-Routing darstellen. Da Blazor aus Razor-Komponenten besteht, erklärt sich somit auch die für mich auf den ersten Blick unlogische Dateiendung *.razor statt *.blazor.

Da Blazor ein Teil von .NET ist, ermöglicht es Entwicklern, welche einen großen Bogen um JavaScript machen wollen, dennoch in der Webentwicklung tätig zu sein und das Wissen, was man sich im C#- und. NET-Ökosystem aufgebaut hat, auch hier zu nutzen.

Einschub: Was ist WASM?

WebAssembly, kurz WASM, ist ein offener Webstandard mit dem Ziel, Bytecode mit nahezu nativer Performance im Browser ausführen zu können und dabei unabhängig von spezifischen Programmiersprachen zu sein. Neben der Kernumsetzung im Browser gibt es aber auch Varianten wie Wasmer, die ohne einen Browser auskommen. Neben C# und F#, wie es im Falle von Blazor bei .NET angesprochen wird, kommen auch andere Programmiersprachen wie Rust, Go, Python, TypeScript, Kotlin oder C++ in Betracht. WASM ist quelloffen und steht unter der APL 2.0.

Server oder WASM?

Um nun Webseiten, welche mit Blazor erstellt werden, zu veröffentlichen, gibt es mehrere Möglichkeiten: Einerseits die traditionelle Herangehensweise mit einem aktiven Webserver im Hintergrund, wo alle Logik auf entfernten Maschinen ausgeführt wird. Diese Art der Webseitenbereitstellung ist der Urvater und auch von PHP, Ruby und Co. bekannt. In unserem Falle wollen wir anfangs jedoch keinerlei Server betreiben und eigentlich auch nichts bezahlen. Aus diesem Grund brauchen wir etwas Statisches. Dies bedeutet, dass der Webserver nur simple HTTP-Anfragen bearbeiten muss, aber sonst keinerlei Logiken der Webseiten aktiv und dynamisch ausführen darf.

Diese Einschränkung erlaubt es uns, die entsprechenden Blazor WASM Seiten auf Diensten wie GitHub Pages oder Codeberg Pages auszuführen, ohne uns um Administration oder Rechnungen am Monatsende kümmern zu müssen. Dies führt mit sich, dass der Client, in unserem Falle der Browser, das Denken übernehmen muss und die hierfür benötigten Bibliotheken beim ersten Besuch der Webseite zu laden hat, was wiederum die initiale Anzeige von Inhalten merklich verlangsamt. Für uns ist dies jedoch erstmal egal.

Zusätzlich zu dem genannten Punkt kann man ebenso nicht 1:1 Logiken von einer Server-basierten Anwendung auf im Browser-laufenden Logiken transferieren. Dies sorgte bei meinem Experiment für Verwirrungen, auf welche ich im Laufe des Artikels noch eingehen werde.

Der Anfang von MyLife.Blazor.Wasm

Das Erstellen des Blazor-Projektes innerhalb der Visual Studio Solution war einfach, da es nur wenige Klicks brauchte. Der Gedankenprozess, welche Art von Blazor-Vorlage man auswählt, war hier schon eine anstrengendere Zeit. Hier zahlt es sich aus, die Entwicklungsumgebung auf Englisch zu stellen – zumindest für mich waren dann Begrifflichkeiten und Beschreibungstexte verständlicher.

Da ich nicht das eingebaute Styling, was die Beispielsseite immer mit sich bringt, haben wollte, entschied ich mich schlussendlich für die “Empty Blazor Web Assembly”-Vorlage. Zu guter Letzt verlinkte ich MyLife.Core noch mit dem nun MyLife.Blazor.Wasm genannten Projekt, um Zugriffe auf die in den ersten Teilen der Artikelserie entstandenen Modelle, Service und Helferlein zu haben.

Gestaltung – bitte ganz einfach

Langjährige Leser von Dr. Windows werden feststellen, dass ich auch für die MyLife.NET Webseite mein Standard-Styling, basierend auf einer class-less CSS-Vorlage, verwendet habe. Peinlicherweise muss ich zugeben, dass ich diese Datei in den Jahren so weit angepasst habe, dass ich meine ursprüngliche Inspiration nicht mehr finde – bis auf den Fakt, dass dieser der Drop-In-CSS-Übersicht stammt.

Mein nicht vorhandenes Tiefenwissen bezüglich Webentwicklung bewirkt, dass die ganze Styling-Struktur stark auf Simplizität getrimmt ist. Anpassungen für unterschiedliche Browser oder gar Responsivität lässt meine CSS-Datei genauso vermissen wie die Wiederverwendung von Variablen oder “prefixed Attributes”.

Trotz dieser Einschränkungen bin ich zufrieden, wie mein erster Versuch auf meinem System in meinem Browser der Wahl aussieht und bedienen lässt. Dies ist bei unseren Basteleien das Wichtigste. Nicht andere müssen es feiern, sondern uns muss es Spaß bereiten und das Gefühl von “Ja, ich habe etwas erreicht!” vermitteln.

CORS: Mein Feind, der zum Freund wurde

Daten von einem Server abzugreifen und im Client darzustellen, ist heutzutage Gang und Gäbe – auch für mich als App-Entwickler ist dies mein tägliches Brot. Aus diesem Grund hatte ich keinerlei Zweifel, dass es vollkommen egal ist, wo mein Daten liegen, Hauptsache diese sind mittels https sicher abrufbar.

Papperlapapp, wenn es um Web Assembly – also lokales JavaScript geht! Hier kommt CORS zum Tragen, was in meinem Falle verhindert, dass ich meine JSON-Dateien von einem anderem Server außer jenem, wo die Blazor-Dateien liegen, abrufen kann. Somit war, als ich versuchte, das Feature zu entwickeln, meine Konsole voller Absturz- und Fehlermeldungen bezüglich Datenzugriffen. Mist – das wird unnötig kompliziert! Auf den ersten Blick ist CORS eine große Behinderung, auf dem zweiten unsere Bastion, was die digitale Sicherheit anbelangt.

Was ist CORS

CORS (Wikipedia) steht für “Cross-Origin Ressource Sharing”. Es handelt sich um eine Sicherheitsrichtlinie, die in allen Browsern implementiert ist. Webseiten können Ressourcen wie Bilder, andere JavaScript-Dateien und Co von verschiedenen Domains laden. CORS wurde entwickelt, um zu verhindern, dass eine Webseite auf Ressourcen von einer anderen Domain zugreift, es sei denn, diese Domain erlaubt es ausdrücklich.

CORS hilft, böswillige Angriffe zu verhindern, indem es sicherstellt, dass nur vertrauenswürdige Domains auf Ressourcen zugreifen können. Ohne CORS könnten Angreifer möglicherweise sensible Daten stehlen oder schädlichen Code ausführen.

Lösung: wwwroot/

Wenn wir das Blazor Projekt in Visual Studio ansehen, fällt uns der spezielle Ordner “wwwroot/” auf. In diesem liegen alle Dateien, welche als normale Datei ausgeliefert werden. Dort befinden sich neben unseren *.css-Dateien auch die index.html Seite, welche initial beim Besuchen der Seite ausgeliefert wird, als auch nun unsere *.json-Dateien, welche wir dann auch im Kontext von WebAssembly anziehen können.

Da ich wie erwähnt keine fremden Server ansprechen kann, muss ich auch nochmal an MyLife.Core herantreten und eine Aggregations-Exporter für meine Medium- und YouTube Feeds schreiben, so dass sich diese auch in WASM-Kontext ansprechen kann.

Hierzu muss ich allerdings in Zukunft noch eine Möglichkeit finden, die aktualisierten JSON-Files via Automatisierung in den angesprochenen Ordner zu schieben. Es bleibt also noch etwas Denkbedarf – wäre ja aber auch langweilig, wenn nicht.

Noch nicht fertig mit MyLife.Blazor.Wasm

Anders als gedacht wird dieser Beitrag nicht das komplette Thema Blazor beziehungsweise das MyLife.Blazor im Allgemeinen abdecken können. Hierzu fehlen noch zu wichtige Eckpunkte der Entwicklung wie der angesprochene CORS-sichere Datenaustausch und die GitHub Action hierhinter, sondern auch wie man Razor-Komponenten am besten strukturiert. In der Web-Entwicklung gibt es hier verschiedene Pattern, vor allem aus dem Lager von React. Diese betreffen grob gesagt, wie sehr man Komponenten “Standalone” bauen sollte, ob sie die dafür benötigten CSS-Informationen mit sich bringen sollten oder es eine große Stylesheet-Datei geben sollte, und noch so weitere Themen, in welchen ich einfach mehr Konfidenz aufbauen möchte, bevor ich diese als erledigt ansehe.

Zusätzlich gibt es noch Arbeiten, was Caching, Routing und weitere Punkte anbelangt, welche abgeschlossen werden müssen, bevor ich keine Angst mehr habe, dass es bereits beim ersten Test in die Brüche geht.

Bin ich enttäuscht?

In den ersten Minuten, nachdem ich die Probleme via CORS feststellte, ja. Denn mein ursprünglicher Plan schien sich in Rauch aufzulösen. Dies, gepaart mit meiner Abneigung gegen Web-Technologien, sorgte dafür, dass Visual Studio hart geschlossen wurde und der Rechner für den Abend aus blieb. Mit der Zeit habe ich erkannt, dass dies ein spannendes Learning ist und dass ich in der Lage bin, mit bisschen extra Gehirnschmalz aus diesem Problem ein Feature zu machen und neue Funktionalität wie den erwähnten Content Creation Feed Aggregator heraus zu ziehen.

Ihr habt Lust mitzuwirken?

Falls ihr euch beteiligen wollt, weil ihr mir zeigen wollt, wie etwas richtig oder einfacher geht, oder ihr euch zum ersten Mal an einer noch übersichtlichen .NET-Solution beteiligen wollt, seid ihr herzlich eingeladen, auf GitHub vorbeizusehen, das Repository zu forken, Issues mit Problemen oder Hinweisen zu eröffnen oder einfach zu stöbern.

Artikel im Forum diskutieren (2)

Über den Autor

Tobias Scholze

Tobias Scholze

Bayrischer Open Source- und Community-Enthusiast, Verfechter des neuen Microsoft und Wandler zwischen den Betriebssystemwelten. #communityrocks Von Herzen ein Nerd mit der festen Überzeugung, dass man gemeinsam und durch den Einsatz von moderner IT die Welt für jeden ein Stückchen besser machen kann.

Anzeige
Anzeige