Abstrakte, leuchtende Spirale in Blau- und Goldtönen, inspiriert von einem digitalen oder fraktalen Muster.

Das starke Duo für alle Fälle

Von der Planung bis zur Ausführung: PowerShell-Skripte mit dem Windows Task Scheduler

Von: Philip Lorenz

In der IT-Administration stellen sich Herausforderungen wie die Bewältigung zeitaufwendiger Routineaufgaben tagtäglich. Eine elegante Lösung bietet die Kombination aus PowerShell und Windows Task Scheduler. Dieser Artikel beleuchtet, wie man durch effektive Skriptplanung mit diesen Tools die Automatisierung von System- und Netzwerkaufgaben optimieren kann.

Grundlagen der Automatisierung mit PowerShell und Task Scheduler

Als leistungsstarkes Automatisierungswerkzeug und Skriptsprache ermöglicht PowerShell die schnelle und effiziente Ausführung von Aufgaben. Es handelt sich dabei nicht nur um eine einfache Befehlszeilenschnittstelle, sondern um ein umfassendes Framework, das für komplexe Automatisierungsszenarien in Windows-Umgebungen entwickelt wurde. Mit seiner objektorientierten Natur erlaubt PowerShell die Manipulation und Verwaltung von Systemkomponenten auf eine Weise, die weit über traditionelle Skriptsprachen hinausgeht.

Auf der anderen Seite steht der Windows Task Scheduler, ein integraler Bestandteil von Windows-Betriebssystemen, der die automatische Ausführung von Aufgaben zu vordefinierten Zeiten oder unter bestimmten Bedingungen ermöglicht. Er bietet eine Benutzeroberfläche für die einfache Planung und Verwaltung von Automatisierungsaufgaben, die von einfachen Skripten bis hin zu komplexen Programmen reichen können. Die Kombination aus PowerShell und dem Windows Task Scheduler schafft eine leistungsfähige Plattform, um wiederkehrende Aufgaben zu automatisieren, Systemwartungen zu planen und auf Systemereignisse zu reagieren.

Im Vergleich zu Linux-Automatisierungstools, wie cron oder systemd, bietet der Windows Task Scheduler eine engere Integration in das Windows-Ökosystem. Während cron in Linux-Umgebungen für die Zeitplanung von Skripten verwendet wird, integriert der Windows Task Scheduler zusätzliche Funktionen wie detaillierte Konfigurationsoptionen, interaktive Benutzeroberflächen und die Fähigkeit, Aufgaben basierend auf einer Vielzahl von Ereignissen auszuführen. Diese Integration ermöglicht eine tiefere Verknüpfung mit Windows-spezifischen Diensten und Anwendungen, was den Task Scheduler zu einem unverzichtbaren Werkzeug für die Windows-basierte IT-Automatisierung macht.

Praktische Umsetzung: Skripte mit dem Task Scheduler planen

Die folgenden Abschnitte zeigen, wie man PowerShell-Skripte im Task-Scheduler planen kann. Die Anlage solcher Scheduled Tasks wird dabei sowohl über die grafische Oberfläche sowie über die PowerShell selbst demonstriert.

Vorbereitung und Test eines Beispiel-Skripts

Zur Demonstration erstellen wir ein einfaches Skript, das Datum und Uhrzeit in eine Log-Datei schreibt. Anhand der Log-Datei kann dabei unabhängig von den Ausgaben des Task Scheduler ermittelt werden, ob das Skript tatsächlich ausgeführt wurde. Speichere das folgende Skript unter dem Pfad C : \ps \scheduledtask\logger . ps1

# logger.ps1
$date = Get-Date
$logPath = "C:\ps\test\log.txt"
$date | Out-File $logPath -Append

Geplante Tasks über die grafische Benutzeroberfläche einrichten

Der einfachste Weg für das Erstellen von Scheduled Tasks führt über die grafische Oberfläche:

  1. Task Scheduler öffnen: Gib ‚Task Scheduler‘ in die Windows-Suche ein und öffne die Anwendung.
  2. Neuen Task erstellen: Wähle im rechten Fensterbereich die Option ‚Create Task‘.
  3. Allgemeine Einstellungen vornehmen: Gib dem Task einen Namen und beschreibe kurz seine Funktion. Wähle ‚Run whether user is logged on or not‘ für eine Ausführung im Hintergrund.

  1. Trigger einstellen: Wechsle zum Tab ‚Triggers‘ und klicke auf ‚New‘. Hier kannst du festlegen, wann das Skript ausgeführt werden soll, beispielsweise täglich um eine bestimmte Uhrzeit.
  2. Aktion definieren: Unter dem Tab ‚Actions‘ klickst du auf ‚New‘. Wähle ‚Start a program‘ und gib powershell  im powershell -File „C:\ps\scheduledtask\logger.ps1“ Feld ‚Program/script‘ ein. Im Feld ‚Add arguments‘ trägst du File „C:\ps\scheduledtask\logger.ps1“ ein.

  1. Bedingungen und Einstellungen: Passe bei Bedarf die Bedingungen und Einstellungen im Task Scheduler an, um die Task deinen Anforderungen entsprechend zu optimieren.
  2. Task speichern: Speichere den Task und führe ihn zur Überprüfung manuell aus. Überprüfe die log.txt, um sicherzustellen, dass das Skript korrekt ausgeführt wurde.

PowerShell-basierte Task-Erstellung

Die Erstellung von Scheduled Tasks lässt sich auch direkt über PowerShell realisieren. Das hat den Vorteil, dass du die Task- Erstellung automatisieren und in Skriptform dokumentieren kannst.


$taskName = "TestLoggerTask"
$scriptPath = "C:\ps\scheduledtask\logger.ps1"

$triggerParams = @{ Daily = $true At = '9am'
}
$trigger = New-ScheduledTaskTrigger @triggerParams

$actionParams = @{
Execute = "Powershell.exe" Argument = "-File $scriptPath"
}
$action = New-ScheduledTaskAction @actionParams

$taskParams = @{ TaskName = $taskName Trigger = $trigger Action = $action
}
Register-ScheduledTask @taskParams

In diesem Skript wird die Splatting-Technik verwendet, um die Parameter für die Trigger- und Action-Erstellung in übersichtlichen und pflegbaren Hashtabellen zu organisieren. Dadurch wird der Code lesbarer und einfacher zu warten.

Scheduled Jobs vs. Scheduled Tasks

In der PowerShell-Automatisierung stehen zwei Hauptkonzepte zur Verfügung: Scheduled Jobs und Scheduled Tasks. Obwohl beide Ansätze ähnliche Ziele verfolgen, unterscheiden sie sich in ihrer Funktionsweise und in ihren Einsatzmöglichkeiten.

Scheduled Tasks sind Teil des Windows Task Schedulers und bieten eine tiefe Integration in das Betriebssystem. Sie können nicht nur PowerShell-Skripte, sondern auch andere Programme oder Skripte ausführen. Scheduled Tasks eignen sich besonders gut für komplexe Szenarien, die eine enge Verknüpfung mit Windows-Diensten und -Anwendungen erfordern. Sie bieten erweiterte Planungsoptionen, wie die Ausführung basierend auf spezifischen Ereignissen oder Zuständen des Systems.

Scheduled Jobs hingegen sind eine PowerShell-spezifische Funktion. Sie ermöglichen es, PowerShell-Befehle und -Skripte zu planen und als Hintergrundjobs auszuführen. Diese Jobs sind eng in die PowerShell-Umgebung integriert, was das Ausführen von PowerShell-Cmdlets und das Verarbeiten von PowerShell-Objekten erleichtert. Scheduled Jobs sind ideal für Aufgaben, die regelmäßig und ohne direkte Benutzerinteraktion durchgeführt werden sollen.

Ein Scheduled Job kann wie folgt angelegt werden:

# Register eines PowerShell Scheduled-Jobs
$trigger = New-JobTrigger -At 10pm -Daily
$jobOption = New-ScheduledJobOption -StartIfOnBatteries

Register-ScheduledJob -Name "MeinPowerShellJob" -ScriptBlock { # DeinIhr PowerShell-Code hier, z.B. ein Skript ausführen
. C:\ps\scheduledtask\logger.ps1
} -Trigger $trigger -ScheduledJobOption $jobOption

Bei der Verwendung von Scheduled Jobs ist jedoch Folgendes zu beachten:

  • Geringere Kompatibilität mit externen Tools: Beispielsweise können Scheduled Tasks auch mittels Ansible angelegt werden, welches wiederum keine Unterstützung für Scheduled Jobs bietet.
  • Einschränkungen bei der Auswahl möglicher Trigger: Scheduled Tasks können unter anderem durch Windows Events (EventLog) angestoßen werden. Scheduled Jobs beschränken sich auf die zeitliche Dimension.

Effektive Strategien zur Fehlervermeidung und Optimierung

Die Automatisierung mit PowerShell und Windows Task Scheduler birgt immense Vorteile, jedoch auch potentielle Fallstricke. Im folgenden werden diese Fallstricke, sowie weitere Optimierungspotentiale beschrieben.

Ausführungskontext und Verzeichnisstruktur

Ein häufiges Missverständnis ist die Annahme, dass PowerShell-Skripte automatisch im Speicherort des Skripts ausgeführt werden. Es ist wichtig zu wissen, dass Skripte standardmäßig im Kontext des Systemverzeichnisses, wie z.B. C:\Windows\system32, gestartet werden. Um Probleme mit relativen Pfadangaben zu vermeiden, sollte der Skriptkontext zu Beginn der Ausführung zum Speicherort des Skripts gewechselt werden. Dies lässt sich mit der PowerShell-Umgebungsvariable $PSScriptRoot realisieren:


Set-Location $PSScriptRoot

Nutzung von Scheduled Tasks im Clusterbetrieb

Für eine erhöhte Verfügbarkeit und Ausfallsicherheit können Scheduled Tasks clustergesteuert eingesetzt werden. Dies bietet Vorteile wie Hochverfügbarkeit durch Failover-Fähigkeiten, zentralisiertes Management und verbesserte Skalierbarkeit. Der Einsatz im Cluster-Modus erfordert ein bestehendes Windows-Cluster-Setup.

$taskName = "ClusteredTask"
$taskType = "ClusterWide"
$clusterName = "MeinCluster"

# ... Konfiguration von Trigger, Principal und Action ...

Register-ClusteredScheduledTask -TaskName $taskName -TaskType $taskType -Cluster $clusterName -Trigger $trigger -Principal $principal -Action

Sicherheitsaspekte und Benutzerberechtigungen

Sicherheit ist ein kritischer Aspekt bei der Automatisierung. PowerShell-Skripte werden im Kontext des angegebenen Benutzers ausgeführt, was bedeutet, dass die Sicherheitsberechtigungen dieses Benutzers berücksichtigt werden müssen. Es ist ratsam, spezielle Benutzerkonten mit minimal notwendigen Berechtigungen zu verwenden, um das Risiko einer übermäßigen Rechtevergabe zu vermeiden.

Monitoring und Protokollierung

Standardmäßiges Logging des Task Schedulers reicht oft nicht aus, um eine detaillierte Übersicht über die Ausführung von Automatisierungsaufgaben zu erhalten. Erweitere das Logging durch PowerShell-spezifische Funktionen wie das Transcript- Feature oder nutze fortgeschrittene Tools wie das PSFramework-Modul für ein umfassendes Monitoring.

Parametermanagement

Die Verwaltung von Übergabeparametern ist ein wesentlicher Bestandteil der Skriptautomatisierung. Anstatt feste Werte direkt im Skript zu definieren, sollten externe Parameterquellen wie Konfigurationsdateien genutzt werden. Dies erhöht die Flexibilität und Wartbarkeit der Skripte. Standardmäßig unterstützt die PowerShell JSON und XML als Datenformate.

Fazit

Gerade im Windows-Umfeld stellt die Kombination von PowerShell und Task Scheduler eine sehr starke und kostenfreie Option dar. Der Feature-Umfang ist natürlich bei weitem nicht so umfassend wie bei kommerziellen Tools zur Job-Steuerung. Für Anwendungsszenarien wie einfachem Reporting oder Aufräumarbeiten (Log-Dateien, etc.) erfüllt der Task Scheduler seinen Zweck. Wichtig ist hierbei lediglich, dass die genannten Best Practices angewendet werden und fehlende Features wie die Verwendung eines Credential- und Key-Stores ergänzt werden.

Über den Autor: Philip Lorenz

Philip Lorenz ist erfahrener DevOps- und Cloud-Engineer mit Schwerpunkt auf Prozessautomatisierung. Mit Begeisterung teilt er sein Wissen in Form von Dienstleistungen und Schulungen und erstellt praxisnahe Lerninhalte rund um die Themen Automatisierung, Cloud-Computing und die Umsetzung moderner KI-Lösungen. Seine Trainings, inspiriert von realen IT-Szenarien, vermitteln anwendbares Wissen, das Teilnehmende direkt in ihre tägliche Arbeit integrieren können.


Diese Beiträge könnten dich auch interessieren:

Loading posts…

Der Beitrag Etwas weniger magisch, aber leichter zu lernen erschien zuerst auf heise academy Blog.

]]> Frameworks – braucht’s die eigentlich noch? https://blog.heise-academy.de/frameworks-brauchts-die-eigentlich-noch/ Tue, 08 Oct 2024 09:42:26 +0000 https://blog.heise-academy.de/?p=7480 Durch Erweiterungen der Webstandards lassen sich die typischen Aufgaben zum Erstellen einer BLOBA mittlerweile ohne weiteres umsetzen. Sind Frameworks deshalb Schnee von gestern? Ob wir Frameworks in der Web-Technologie noch brauchen erfährst du in diesem Beitrag.

Der Beitrag Frameworks – braucht’s die eigentlich noch? erschien zuerst auf heise academy Blog.

]]>

Frameworks – braucht’s die eigentlich noch?

Von Brennpunkten in der IT-Landschaft und neuen Interpretationen alter Probleme

Von: Katja Potensky

Ich bin zwar nicht bekannt dafür, aus der Bibel zu zitieren, aber hin und wieder passt eine Passage einfach:

Es gibt nichts neues unter der Sonne. – Prediger 1,9

Daran fühlte ich mich letzte Woche erinnert bei einer Diskussion zur Frage, ob es Frameworks noch brauche. Du kannst dir sicher vorstellen, wie lebhaft solch ein Diskurs geführt wird. In den folgenden Absätzen möchte ich die verschiedenen Blickwinkel sowie meine Two Cents zum Thema Frameworks mit euch teilen.

Was ist überhaupt ein Framework?

Ein Framework ist eine Sammlung von Software mit einer zugehörigen Sammlung an Kompromissen. – Peter Kröner

Diese Definition kam zu Beginn der angesprochenen Diskussion auf und ich halte sie für die erste sinnvolle überhaupt. Denn sie deutet bereits darauf hin, dass wir es hier nicht mit einer rein technischen Fragestellung zu tun haben. Dennoch möchte ich den technischen Blickwinkel als Ausgangspunkt wählen.

Worin liegt der technische Bedarf?

Gibt es einen technischen Bedarf für C oder Java? Warum programmieren wir nicht alle einfach Assembler? Der Bedarf richtet sich nicht nur nach den Zielen, sondern auch nach den Aufwänden. Man wollte irgendwann nicht mehr in Assembler programmieren, also haben schlaue Menschen begonnen, die typischen Aufgaben zu abstrahieren und irgendwann kam unter anderem C dabei raus. Später hat sich herausgestellt, dass man auch in C viele wiederkehrende Aufgaben lösen musste, also hat sich über ein paar Umwege Java ergeben. Du siehst also, das Ganze ist ein iterativer Prozess.

Auf solchem Wege wurde auch die Aufgabe, ein buntes Kästchen im Browser zu bauen, in das man etwas reintippen kann, immer mehr abstrahiert. Diese Abstraktionen wurden zu den Frameworks, die wir heute kennen. Mittlerweile sind wiederum viele bis alle typischen Aufgaben zum Erstellen einer BLOBA (Boring Line-of-Business Application), bei denen ein Framework in den letzten zehn Jahren geholfen hat, durch Erweiterungen der Webstandards ohne größere oder sogar mit weniger Problemen umsetzbar.

Ich rate hier dringend dazu, auf MDN die Liste der HTML-Elemente alle paar Jahre durchzugehen, genauso wie die Liste der Web-APIs. Dialoge, Dropdowns oder auch die meisten Validierungen sollte man im Jahr 2024 wirklich nicht mehr mit einer teuren Component Library umsetzen.

Auch wenn es um das Thema Bundling und CI/CD geht, lohnt sich ein Blick über den Tellerrand. Gerade hier führt der Einsatz schwergewichtiger Lösungen gerne zu unvorhergesehenen Problemen.

Tipp: „Code is a liability, not an asset“ gilt auch für jenen Code, den wir nicht selbst schreiben. Wenn sich Abhängigkeiten ungünstig verhalten, ist meistens das einzige, was wir heutzutage tun können, einen Bug Report zu erstellen und die Ohren steif zu halten. Oder hast du schon mal probiert, eine geforkte Version von Angular auszurollen? ;)

Aber gut, dieses Argument schaut auf die bisherigen Umstände. Was ist, wenn wir in die Zukunft blicken?

Der Blick nach vorne

Gehen wir rein theoretisch davon aus, dass Angular, React, Vue etc. ihre Repositories und Packages löschen und wir alle unsere BLOBAs mit HTML und gezielt eingesetztem Javascript bauen.

Einer der Trends unserer Zeit ist ganz klar KI, man kann heutzutage im Browser mittels WebGPU Zugriff auf die GPU erlangen. Jetzt wäre es nicht allzu weit hergeholt, dass für diverse Use-Cases auf vielen Websites Chatbots implementiert werden sollen. Und zwar auf so vielen, dass es sich zur Vereinfachung des Anwendungsfalls auszahlt, Libraries darum herum zu schreiben. Vielleicht kommen auch Bezahlmöglichkeiten mittels Payment Request API dazu und ein paar andere Dinge, die so typisch werden, dass wir wiederum eine Reihe von Libraries unter der Annahme von gewissen Kompromissen auf eine spezifische Art und Weise verbinden, die wir gut finden… und prompt haben wir unser nächstes Framework geschaffen.

Wir können also davon ausgehen, dass es immer (neue) Frameworks geben wird. Denn so wunderbar die Webstandards sind, sie können und sollen eben nicht meinungsgetrieben sein. Selbst die Gamepad API existiert, weil es ausreichend Bedarf dafür gab und nicht umgekehrt. Neue Bedürfnisse sollten nicht durch Webstandards verprobt werden, sondern durch Libraries und Frameworks. Aber wer würde solche neuen Frameworks wohl verwenden?

„Apes together strong“

Wie viele Frameworks, die uns geholfen haben Formulare und Seitennavigationen zu bauen, gibt es wohl?

2011 habe ich einige JS-Files geschrieben, die mittels beliebiger Attribute an HTML-Elementen diese Elemente um eine beliebige Funktionalität erweitern können. Das weiß kaum jemand, da ich diese Idee zum einen nicht verbreitet habe. Zum anderen wurde ich ein paar Wochen später mit AngularJS konfrontiert und dachte mir: „Hey, die Idee hatte schon jemand.“ Also habe ich meinen eigenen Code verworfen und stattdessen AngularJS eingesetzt, weil es zum damaligen Zeitpunkt genau das tat, was ich zum damaligen Zeitpunkt brauchte. Es gibt Ideen, um die Menschen sich versammeln, und das hat gleich mehrere Auswirkungen.

Brennpunkte

Egal ob man diesen Ansatz gut findet oder nicht, egal ob man React oder Angular mag – durch die Existenz von Frameworks bilden sich gewissermaßen Brennpunkte in der IT-Landschaft. Orte, an denen Menschen zusammen kommen, ihre Ideen einbringen und Richtlinien rund um die vermeintlich korrekte (idiomatische) Verwendung der jeweiligen Lösung erarbeiten.

Diese Richtlinien mögen uns gefallen oder nicht, sie ermöglichen einen effizienteren Austausch in Projekten und ein schnelleres Onboarding von neuen Personen. Durch die kontinuierliche Anwendung dieser Richtlinien werden sie innerhalb gewisser Grenzen laufend verbessert. Aber was, wenn man an diese Grenzen stößt und sich nicht damit abfinden will?

Dissonanz

Zu Deutsch: Unstimmigkeit, Missklang. Stell dir vor, du kannst nicht damit leben, dass AngularJS die Änderungen an Objekten periodisch und recht teuer auf den Bildschirm bringt. Ganz egal, wie viel optimiert wird, hier ist das grundlegende Konzept das Problem und irgendwann stößt man an die Grenzen des technisch Möglichen.

Wenn das ein Knockout-Kriterium ist, muss man besagten Brennpunkt verlassen, zurück ans Zeichenbrett und von Null auf neue Wege gehen. Das mag erst mal unglaublich schwer klingen, aber man hat einige gewaltige Vorteile dabei: Man weiß, was das Problem ist, wie man es nicht löst und was die Erwartungshaltungen sind.

Und nach ein paar Monaten Hin und Her, Recherche und Trial-and-Error hat man dann wahrscheinlich einen Weg, um den Anwendungsfall, an dem die vorige Idee gebrochen ist, besser umzusetzen. Um es mit den Worten von Soichiro Honda zu sagen:

„Racing improves the breed.“

Die Frage ist dann eher, ob das, was wir jetzt besser machen können, die Verbesserung überhaupt verdient hat.

Ein alter Hut?

Sind Frameworks also bloß immer neue Interpretationen von ewig alten Problemen? Nun, irgendwie schon, aber irgendwie auch nicht. Mir fällt hierzu eine Anekdote ein. Ich fand Liebeslieder immer kitschig und sinnlos, bis ich mal einen Musiker bei einer Show sagen hörte: „Natürlich wurden die Worte ‚I love you‘ schon tausende Male vertextet, natürlich ist jedes Liebeslied irgendwie gleich. Aber vielleicht, nur vielleicht, wurde es ja noch nicht mit den selben Gefühlen gesungen, die du dabei spürst. Und selbst wenn, warum sollte dich das davon abhalten, ‚I love you‘ zu sagen?“

Vielleicht können wir darüber hinweg sehen, welches Framework technisch besonders ausgefeilt ist, und einfach das verwenden, das am besten zur aktuellen Situation passt. Und wenn die aktuelle Situation bloß erfordert, eine Reihe von Formularen zu erstellen, könnte man ‚I love you‘ mal ganz ohne jegliche Schnörkel sagen. Denn der größte Brennpunkt in der IT-Landschaft sind immer noch die Webstandards.

Über die Autorin: Katja Potensky

Katja ist Software Engineer bei adesso und seit 2012 in einem professionellen Setting tätig. Sie lässt sich nicht auf einzelne Aspekte eines Systems limitieren, und hat von daher schon eine Vielzahl an Projekten in unterschiedlichsten Rollen und Teamgrößen umgesetzt. Aus der Arbeit mit unterschiedlichsten Webtechnologien hat sich ein fundierter Anspruch an Codequalität und korrektes Programmverhalten entwickelt den sie auch weitergeben möchte. Sie brennt für Code der leicht zu lesen ist und nicht bedingt die halbe Codebase im Kopf zu behalten um zu verstehen was “da gerade passiert”.


Diese Beiträge könnten dich auch interessieren:

Loading posts…

Der Beitrag Frameworks – braucht’s die eigentlich noch? erschien zuerst auf heise academy Blog.

]]> Fullstack React: Das ist neu und wichtig https://blog.heise-academy.de/fullstack-react-das-ist-neu-und-wichtig/ Mon, 12 Aug 2024 08:19:28 +0000 https://blog.heise-academy.de/?p=7320 Das React-Team hat die Empfehlung ausgesprochen, React-Anwendungen künftig nur noch mit einem Fullstack-Framework zu entwickeln. Seitdem ist eine leidenschaftliche Diskussion über die Fürs und Widers dieser Entscheidung im Gang. Ein Überblick der Begriffe, Konzepte und Ideen.

Der Beitrag Fullstack React: Das ist neu und wichtig erschien zuerst auf heise academy Blog.

]]>

Fullstack React: Das ist neu und wichtig

Ein Überblick der Begriffe, Konzepte und Ideen

Von: Nils Hartmann

Das React-Team hat die Empfehlung ausgesprochen, React-Anwendungen künftig nur noch mit einem Fullstack-Framework zu entwickeln. Seitdem ist eine leidenschaftliche Diskussion über die Fürs und Widers dieser Entscheidung im Gang. Außerdem schwirren viele neue Begriffe, Konzepte und Ideen durch das React-Ökosystem. Dieser Artikel soll eine Orientierungshilfe bieten.

Klassisch werden React-Anwendungen als Single-Page-Anwendung (SPA) gebaut. Dabei wird der JavaScript-Code der Anwendung in den Browser geladen und dort ausgeführt. Der Server dient lediglich dazu, den JavaScript-Code auszuliefern – wie er es auch mit anderen statischen Assets wie CSS- oder Bild-Dateien verfährt. Sobald der JavaScript-Code vom Browser geladen und ausgeführt wurde, ist die Anwendung interaktiv und kann vom Benutzer bedient werden. Das läuft in der Regel sehr flüssig, weil sämtliche Interaktionen auf dem Client stattfinden und keine Server-Requests zum Neurendern der Darstellung notwendig sind.

Die Schattenseite ist, dass die Anwendung erst dargestellt werden kann, wenn der notwendige JavaScript-Code geladen wurde. Dieser muss dann noch geparst und ausgeführt werden. Das dauert naturgemäß länger, als wenn der Browser fertigen HTML-Code vom Server bekommt und diesen darstellt. Gerade für Anwendungen bzw. Websites, bei denen es auf eine schnelle erste Darstellung ankommt, zum Beispiel Landing- oder Produkt-Seiten, können SPAs zu langsam sein. Um dieses Problem zu lösen, kann man Seiten einer Anwendung mit Server-Side Rendering (SSR) auf dem Server vorrendern. In diesem Fall läuft auf dem Server ein JavaScript-Prozess, der den Request entgegennimmt, dort React verwendet um eine Seite zu rendern und das Ergebnis als fertigen HTML-Code zum Browser schickt. Der Browser kann die HTML-Seite dann unmittelbar anzeigen.

Aber auch bei diesem Ansatz lädt der Browser nach der initialen Darstellung den JavaScript-Code der Anwendung und führt diesen aus, damit die Anwendung interaktiv wird. Dieser Vorgang wird auch als Hydration bezeichnet. Das Laden und Ausführen des JavaScript-Codes ist bei einigen Seiten (oder Teilen von Seiten) aber nicht unbedingt erforderlich. JavaScript wird im Browser nämlich grundsätzlich nur für die interaktiven Teile einer Anwendung benötigt, um zum Beispiel auf Benutzereingaben reagieren zu können. Für statischen Content, der auf dem Server gerendert worden ist, wäre kein JavaScript erforderlich.

An diesem Punkt setzen Fullstack-Frameworks wie Gatsby, Next.js oder Remix an. Da diese Frameworks einerseits zwar React verwenden, andererseits darüber hinaus auch weitere Bibliotheken und Frameworks (etwa für Build, Bundling und Routing) integrieren, werden sie auch als Meta-Frameworks bezeichnet.

Ähnlich wie beim serverseitigen Rendern schicken auch diese Frameworks eine fertige Darstellung einer Seite an den Browser. Allerdings wird hierbei der JavaScript-Code für statische Komponenten nicht zum Browser übertragen, da er dort nicht benötigt wird. Der Browser muss bei diesen Anwendungen also, wie bei Single-Page-Anwendungen, einmalig den JavaScript-Code für das Framework runterladen. Danach wird aber nur noch der JavaScript-Code für jene Komponenten benötigt, die auf dem Client auch interaktiv sein sollen, und nicht mehr für jede Komponente wie bei Single-Page-Anwendungen. Dieser Ansatz wird als Partial Hydration bezeichnet.

Und Partial Hydration geht noch weiter: Nach einer Interaktion, zum Beispiel nach dem Wechseln zwischen Ansichten von zwei Produkten in einem Shop-System, muss nicht die gesamte Seite auf dem Server neugerendert und zum Client übertragen werden. Der Server schickt dann nur die Teile neu, die sich gegenüber der vorherigen Darstellung geändert haben. Das kann zum Beispiel eine neue Darstellung der Produktdaten im Hauptbereich sein, während für die unveränderte Sidebar kein neuer Code benötigt wird.

Unabhängig davon, ob nur ein Teil einer Website ausgetauscht wird oder die ganze Website, kann es auf Serverseite zu unterschiedlich langen Wartezeiten kommen, bis eine Komponente vollständig gerendert werden kann. Möglicherweise ist das Laden der Daten für ein Produkt schneller als das Laden der dazugehörigen Kommentare. In diesem Fall kann React angewiesen werden, auf welche Komponenten beim Rendern gewartet werden soll und welche zunächst nur einen Platzhalter zeigen. Das ist in React mithilfe von Streaming und der Suspense API möglich. Je nach fachlicher Anforderung kann damit deklarativ beschrieben werden, ob zum Beispiel auf das Rendern von Produkt- und Kommentaransicht gewartet werden soll, oder ob eine der beiden Komponenten schon zum Client geschickt werden soll, auch wenn die andere noch fertig gerendert wird.

Mit vielen Fullstack-Frameworks können interaktive Komponenten so gebaut werden, dass sie im Browser auch ohne JavaScript funktionieren, aber dennoch eine Grundfunktionalität zur Verfügung stellen. Etwa wenn das JavaScript wegen schlechter Internetverbindung nicht oder nur langsam lädt. Sobald das JavaScript dann bereit ist, kann die Anwendung dem Benutzer verbesserte Features zur Verfügung stellen, die ohne JavaScript nicht oder nur eingeschränkt möglich sind (zum Beispiel client-seitige Validierungen). Dieses Verhalten wird auch als Progressive Enhancement bezeichnet, weil die Anwendung grundsätzlich funktioniert, aber nach-und-nach durch das Laden von JavaScript erweitert wird.

Die technische Umsetzung dieser Lösungen unterscheidet sich in den Frameworks. Allerdings bietet React neuerdings die React Server Components (RSC) an. Das sind Komponenten, deren JavaScript nicht im Client vorhanden sein soll, weil sie ausschließlich statischen Content erzeugen. Obwohl der Name es suggeriert, werden Server Components nicht ausschließlich auf dem Server gerendert, sondern können auch schon zur Build-Zeit gerendert werden. Damit stehen sie dann zur Laufzeit bereits vollständig zur Verfügung und müssen nicht bei jedem Request erneut erzeugt werden. Das funktioniert aber nur, wenn sie keine Request-spezifischen Informationen benötigen. Da diese Komponenten auf dem Server (zur Lauf- oder Build-Zeit) gerendert werden, haben sie Zugriff auf die Serverinfrastruktur und können deshalb beispielsweise auf das Filesystem oder Datenbanken direkt zugreifen. Damit können sie zumindest Teile klassischer Backend-Aufgaben übernehmen, weswegen solche Anwendungen dann auch als Fullstack-Anwendungen bezeichnet werden.

Um React Server Components in der eigenen Anwendung zu verwenden ist ein komplexes Tooling notwendig. Es wird ein RSC-kompatibler Server (zur Laufzeit) und/oder ein RSC-kompatibles Build Tool benötigt. Auch aus diesem Grund hat das React-Team die eingangs erwähnte Fullstack-Empfehlung ausgesprochen, denn das Implementieren solcher Tools ist nicht trivial.

Natürlich stehen in React auch weiterhin die „klassischen“ Komponenten zur Verfügung, die in Abgrenzung nun als Client Components (CC) bezeichnet werden. Auch hier ist der Name leider irreführend, denn Client Components können auch auf dem Server (vor-)gerendert werden. Im Gegensatz zu den Server Components wird ihr JavaScript-Code aber auch auf den Browser übertragen und dort bei Bedarf ausgeführt. Diese Komponenten enthalten die interaktiven Teile der Anwendung und entsprechen den klassischen Komponenten, die aus React bekannt sind. Da die APIs der beiden Komponenten-Arten weitgehend identisch sind, ist es für das Build Tool nicht immer erkennbar, ob sie (und damit auch der Code, den sie verwenden) auf dem Server- und/oder auf dem Client ausgeführt werden sollen. Daher müssen einzelne Code-Stellen mit einer React-Direktive („use client“ bzw. „use server“) gekennzeichnet werden.

Über den Autor: Nils Hartmann

Nils Hartmann ist freiberuflicher Softwareentwickler und -architekt aus Hamburg. Er beschäftigt sich seit mehr als 20 Jahren mit der Entwicklung von Software. Sein Schwerpunkt liegt auf Java-basierten Backend-Services mit Spring Boot sowie der Entwicklung von Frontends mit React und TypeScript. In seinen Projekten setzt er gerne GraphQL ein. Er ist Co-Autor des Buchs „React – die praktische Einführung“ (dpunkt.Verlag).


Diese Beiträge könnten dich auch interessieren:

Loading posts…

Der Beitrag Fullstack React: Das ist neu und wichtig erschien zuerst auf heise academy Blog.

]]> "' data-attributes='{"layout":"grid","selectedCategories":[19],"postsPerPage":3,"postsExclude":[7168],"isExcludeCurrent":true,"contentBG":{"color":"var(u002du002dbase)","styles":"background-color: #f4f2fc;"},"isFImgLink":true,"titleColor":"var(u002du002dcontrast)","isMetaAuthorLink":false,"metaCategoryIn":"image","metaLinkColor":"rgba(0, 0, 0, 1)","metaIconColor":"var(--contrast)","metaColorsOnImage":{"color":"#fff","bg":"var(--heise-blau)"},"excerptLength":45,"readMoreLabel":"Weiterlesen","readMoreColors":{"color":"#fff","bg":"var(--academy-red)"},"readMoreHovColors":{"color":"#fff","bg":"var(--heise-blau)"},"readMorePadding":{"vertical":"12px","horizontal":"35px","side":2,"top":"12px","right":"35px","bottom":"12px","left":"35px"},"align":"wide","subLayout":"default","columns":{"desktop":3,"tablet":2,"mobile":1},"columnGap":15,"rowGap":15,"isContentEqualHight":true,"sliderHeight":"350px","content":{"height":"auto"},"postType":"post","queryPreset":"","taxonomyRelation":"AND","selectedTaxonomies":[],"selectedTags":[],"isPostsPerPageAll":false,"postsAuthors":[],"postsOrderBy":"date","postsOrder":"desc","postsSearch":"","postsOffset":0,"postsInclude":[],"isExcludeSticky":false,"isPagination":false,"paginationPrevLabel":"Prev","paginationNextLabel":"Next","paginationColors":{"color":"#fff","bg":"#146EF5"},"paginationHovColors":{"color":"#fff","bg":"#070127"},"paginationPadding":{"vertical":"8px","horizontal":"15px"},"paginationSpacing":"15px","loadMore":{"type":"","alignment":"center","scrollTop":{"enabled":false,"offset":50},"infinityScroll":{"offset":-100,"spinner":true,"label":"Loading..."},"button":{"label":"Load More"}},"contentAlign":"left","hoverContentBG":{"color":""},"contentPadding":{"vertical":"20px","horizontal":"25px"},"border":{"width":"1px","color":"#0c0d3c1a","radius":"5px"},"hoverBorder":{"width":"1px","color":"#0c0d3c1a","radius":"5px"},"shadow":[],"hoverShadow":[],"sliderIsLoop":true,"sliderIsTouchMove":false,"sliderIsAutoplay":true,"sliderAutoplayOptions":{"delay":1.5},"sliderSpeed":1.5,"sliderEffect":"slide","sliderIsPage":true,"sliderIsPageClickable":true,"sliderIsPageDynamic":true,"sliderPageColor":"#146EF5","sliderPageWidth":"15px","sliderPageHeight":"15px","sliderPageBorder":{"radius":"50%"},"sliderIsPrevNext":true,"sliderPrevNextColor":"#146EF5","tickerDirection":"up","tickerSpeed":"slow","tickerInterval":2000,"tickerHeight":"0px","tickerVisible":3,"tickerIsMousePause":true,"newsTicker":{"label":"Trending Now","theme":"theme1","type":"vertical","direction":"up","speed":3000,"animation":"slide","pauseOnHover":true},"magazine":{"subLayout":"left-image","minHeight":{"desktop":"450px","tablet":"400px","mobile":"350px"}},"elementsSort":["title","meta","excerpt"],"isFImg":true,"fImgSize":"full","fImgFitting":"cover","isTitle":true,"isTitleLink":true,"titleTypo":{"fontFamily":"Roboto","fontSize":{"desktop":"25px","tablet":"22px","mobile":"20px"},"googleFontLink":"https:\/\/fonts.googleapis.com\/css2?family=Roboto&display=swap"},"titleMargin":{"side":4,"bottom":"15px"},"isMeta":true,"isMetaAuthor":true,"metaAuthorIcon":"","isMetaDate":true,"metaDateFormat":"M j, Y","metaDateIcon":"","isMetaCategory":true,"metaCategoryIcon":"","metaTaxonomies":{"selected":[]},"isMetaReadTime":false,"metaReadTimeIcon":"","isMetaReadTimeSec":false,"metaReadTimeLabel":"Min read","isMetaComment":false,"metaCommentIcon":"","metaTypo":{"fontSize":{"desktop":"13px"},"textTransform":"uppercase"},"metaTextColor":"","metaMargin":{"side":4,"bottom":"15px"},"isExcerpt":true,"isExcerptFromContent":false,"isEllipsisOnExcerpt":false,"excerptAlign":"justify","excerptTypo":{"fontSize":{"desktop":"15px"}},"excerptColor":"","excerptMargin":{"side":4,"bottom":"10px"},"isReadMore":true,"readMorePosition":"auto","isLinkNewTab":false,"readMoreAlign":"left","readMoreTypo":{"fontSize":{"desktop":"14px"},"textTransform":"uppercase","fontWeight":600},"readMoreBorder":{"radius":"3px"},"image":{"width":"100%","height":"60%","lazyLoad":false,"defaultImage":"","styles":{"grayScale":false,"hoverGrayScale":false,"border":{"width":"0px","style":"none"},"radius":{"top":"0px","right":"0px","bottom":"0px","left":"0px"},"hoverRadius":{"top":"0px","right":"0px","bottom":"0px","left":"0px"},"shadow":[],"hoverShadow":[],"margin":{"top":"","right":"","bottom":"","left":""},"hoverAnimation":"none"}},"title":{"tag":"h3","limit":{"type":"word","value":10,"ellipsis":false},"styles":{"textAlign":"","hoverColor":""}},"meta":{"gap":"10px","separator":"","sorting":["author","date","category","readTime","comment","viewCount","taxonomy"],"date":{"timeAgo":false},"viewCount":{"isVisible":false,"icon":""},"styles":{"alignment":"","hoverColor":"","linkHoverColor":"","iconHoverColor":"","separatorColor":""}},"excerpt":{"from":"excerpt","styles":{"hoverColor":""}},"readMore":{"icon":"","iconGap":"10px","iconPosition":"right","styles":{"hoverBorder":{"radius":"3px"},"hoverAnimation":"none","shadow":[],"hoverShadow":[]}},"categoryOnImage":{"styles":{"position":"bottomLeft","padding":{"top":"3px","right":"8px","bottom":"3px","left":"8px"},"radius":{"top":"3px","right":"3px","bottom":"3px","left":"3px"},"margin":{"top":"0px","right":"0px","bottom":"10px","left":"10px"}}},"gbBlockCondition":"","gbBlockConditionInvert":false,"currentPostId":7168}' >
Loading posts…