Das migrieren wir auch noch

EnterpriseTales: Auf dem Weg zur SPA

Sven Kölpin

Immer mehr Webanwendungen werden heutzutage als Single Page Application (SPA) umgesetzt. Langsam aber sicher manifestiert sich dieser Trend auch im Enterprise-Umfeld. Dabei stellt sich hier die Frage, ob und vor allem wie eine klassische Webanwendung zu einer SPA migriert werden kann.

Anfänglich waren SPAs vor allem bei Start-ups beliebt. In gestandenen Unternehmen hingegen wurde der Trend, Benutzungsoberflächen ausschließlich auf Basis von JavaScript zu entwickeln, vornehmlich als Hipstergetue belächelt. Technologieriesen wie Facebook, Twitter und Netflix haben uns in den letzten Jahren allerdings beeindruckend gezeigt, dass SPAs auch bei sehr großen Anwendungen funktionieren. Mittlerweile wird nun auch in vielen Unternehmen geplant, serverseitig entwickelte Webanwendungen auf moderne SPAs umzustellen.

Die anderen machen das doch auch

Häufig ist der Wunsch, bestehende Webapplikationen mit einer modernen Technik neu zu entwickeln, wenig von einer konkreten funktionalen Notwendigkeit getrieben. Es spielt die Angst, technogisch abgehängt zu werden, die größte Rolle. Sätze wie: „Aber bei Facebook oder Netflix machen die das auch so“, sind hier ein typisches Indiz. Aber auch eine – häufig durch technische Schulden getriebene – Unzufriedenheit mit dem aktuellen Technologie-Stack löst die Sehnsucht zur Veränderung aus – aka „Mit React oder Angular hätte ich das Feature bestimmt schon lange umgesetzt“.

Technologische Hypethemen und Trends dürfen natürlich nicht einfach ignoriert werden. Ein Unternehmen lebt schließlich von Innovationen. Zudem haben wir bereits zu oft schmerzhaft erfahren müssen, dass Legacy-Systeme sich irgendwann zu echten kritischen Pfaden entwickeln können. Vor allem, wenn es im Unternehmen aufgrund von veralteter Technik kein Know-how mehr für die Systeme gibt. Eine blinde Adaption eines jeden Trends ist aber selbstverständlich genauso wenig anzustreben. Schließlich ist jede technologische Veränderung ein erheblicher Kosten- und Risikofaktor, sodass der Nutzen einer Migration stets genauestens geprüft werden muss. Das ist auch bei der Umstellung hin zu einer SPA nicht anders, denn hier stehen schließlich grundlegende architektonische Eingriffe und technische Veränderungen bevor.

Das Prinzip einer SPA

SPAs unterscheiden sich von Webapplikationen, die mithilfe von serverseitigen Frameworks wie JSF oder Spring MVC entwickelt wurden. Dort ist nämlich die Render- und UI-Logik vorwiegend auf der Serverseite implementiert – Entwickler müssen die Java-Welt also während der Implementierung fast nicht verlassen. Bei SPAs hingegen findet eine Verlagerung der Logik in den Browser statt. Die Kenntnis von JavaScript und anderen Webtechnologien ist hier also eine Grundvoraussetzung.

Lesen Sie auch: Nachhaltige Webarchitekturen: Warum REST und SPAs nicht immer die Lösung sind

SPAs werden im Browser durch den JavaScript-Code generiert. Serverseitig gerendertes HTML ist also überflüssig, weshalb der Einsatz eines klassischen Webframeworks nicht mehr zwingend notwendig ist. Es gibt durchaus Möglichkeiten, SPAs initial auf dem Server zu rendern, um ein schnelleres Laden der Seite zu ermöglichen. Trotzdem ist das nicht mit klassischen, serverseitigen Frameworks zu vergleichen. Die Aufgabe des Servers besteht bei SPAs also nicht mehr im Erstellen des User Interface, sondern hauptsächlich in der Auslieferung reiner Daten, die von der SPA konsumiert werden (häufig im JSON-Format).

Wann lohnen sich SPAs?

Natürlich gibt es, wie so oft, keine eindeutige Antwort darauf, ob sich die Umstellung auf eine SPAs für ein Unternehmen lohnt. Allenfalls lassen sich aus den architektonischen und technologischen Eigenheiten von SPAs bestimmte funktionale und nichtfunktionale Anforderungen ableiten, für die sie sich besonders gut eignen. Bei SPAs liegen die UI-Logik und die benötigten Daten vornehmlich im Client, weshalb auch komplexe Benutzerinteraktionen stets flüssig abgebildet werden können. Verglichen mit herkömmlichen Webanwendungen sind sie während der Benutzung außerdem weniger netzwerkintensiv. Schließlich müssen keine HTML-Fragmente oder sogar ganze HTML-Seiten mehr übertragen werden. SPAs vermitteln einem Benutzer so das Gefühl, eine native Anwendung (Web-App) zu benutzen. Und in Zeiten von Facebook und Co. hat sich das zu einer grundlegenden Erwartungshaltung des Benutzers an eine Webanwendung entwickelt. Vor allem bei Consumer-Anwendungen kann sich eine Migration also lohnen.

Auch für die Entwicklung von mobilen Webanwendungen eignen sich SPAs durch den vergleichsweise geringen Netzwerk-Footprint besonders. Zudem können durch die Nutzung moderner Browser-APIs, wie LocalStorage, IndexedDB oder ServiceWorkers, relativ problemlos Offline-First- und Optimistic-Update-Ansätze implementiert werden. Und weil sich Progressive Web-Apps langsam aber sicher zu einer ernstzunehmenden Technik für mobile Applikationen entwickeln, kann die Implementierung mobiler Anwendungen auf Basis von SPAs bereits jetzt eine clevere Investition sein.

Auch aus architektonischer Sicht bieten SPAs Vorteile. Weil die Server nicht mehr für die Generierung des UI verantwortlich sind, agieren sie nun häufig als statuslose Datenlieferanten. Deshalb können bei Bedarf Lasten leichter verteilt werden, was bei statusvollen Webanwendungen oftmals eine Herausforderung ist. Zusätzlich werden die eigenen Server durch die Nutzung der Rechenleistung der jeweiligen Clients entlastet, weil die Benutzeroberfläche nun im Browser und nicht mehr auf dem Server gerendert wird. Bei Anwendungen mit einer hohen Nutzerlast und/oder rechenintensiven Prozessen bieten SPAs also unterm Strich den Vorteil einer besseren Skalierbarkeit.

Und wann eher nicht?

Vor allem bei Webanwendungen, die nicht im Consumer-Bereich angesiedelt sind und die gleichzeitig stark formularbasiert arbeiten, ist die Notwendigkeit einer Migration genauer zu prüfen. Formularbasierte Applikationen, also Anwendungen, die fast ausschließlich aus einfachen Eingabemasken bestehen, haben in der Regel eine vergleichsweise geringe Komplexität in der Benutzerinteraktion. Zudem werden sie zumeist von stationären Desktop-PCs mit schneller Internetanbindung bedient. Die Migration hin zu einer SPA würde hier aus Sicht des Benutzers also allenfalls geringe Vorteile bieten. Des Weiteren benötigen solche Webanwendung viele Validierungsmechanismen, was bei der Entwicklung von SPAs ein wenig aufwändiger ist. Schließlich sollen Eingabedaten mindestens auf dem Server, im besten Fall aber schon vorher auf dem Client validiert werden. Das lässt sich mithilfe von serverseitig rendernden Frameworks wie JSF oder Vaadin schneller umsetzen, weil hier der clientseitige Code größtenteils automatisch generiert wird.

Es darf weiterhin nicht vergessen werden, dass SPAs moderne und schnelle Browser voraussetzen – im Kontext von Enterprise-Anwendungen leider nicht immer eine Selbstverständlichkeit. Schwache Clients und veraltete Browser können die Vorteile von SPAs zunichte machen und sogar das Gegenteil bewirken. Eine genaue Analyse der später nutzenden Endgeräte ist also unabdingbar.

Architektonische Entscheidungen und Frameworks

Vor einer Migration gilt es, technologische und architektonische Fragen zu klären. Eine der Wichtigsten ist, wie die HTTP-Schnittstelle gestaltet werden soll, die später von der SPA benutzt wird. Hier gibt es im Groben zwei Optionen: Erstens, das API ist eine rein interne Schnittstelle, die ausschließlich der SPA dient. Zweitens, es ist ein öffentliches API, das sowohl durch die SPA als auch von Drittsystemen konsumiert wird. Letzteres ist in der Regel weitaus komplexer. Bei öffentlichen Schnittstellen spielen nämlich Themen wie Security, Versionierung, Rate Limiting, Caching oder Schnittstellendokumentation eine besondere Rolle. Zudem ist ein möglichst standardkonformes API-Design (Sichwort: RESTful API-Design) von großer Bedeutung.

Lesen Sie auch: Welches JavaScript-Framework passt zu mir?

Als weitere Frage stellt sich natürlich, welches JavaScript-SPA-Framework für die Umsetzung gewählt werden soll. Die gute Nachricht: Die Zeiten, in denen jede Woche unzählige neue SPA-Frameworks und Tools veröffentlich wurden, scheinen sich dem Ende genähert zu haben. Die JavaScript-Fatigue ist also überwunden, und es kann sich bei der Wahl des SPA-Frameworks im Prinzip auf die beiden Big Player React (Facebook) und Angular (Google) konzentriert werden. Und egal, für welches dieser SPA-Frameworks man sich entscheidet, beide bieten heutzutage umfangreiche Tools und Tutorials für das Einrichten neuer Projekte an (angular-cli, create-react-app). Ein schneller und einfacher Einstieg in die jeweilige Welt ist also gegeben. Auch die Verwendung von typisierten Aufsätzen für JavaScript, vor allem TypeScript bei Angular oder Flow bei React, ist heutzutage leicht möglich und wird teilweise sogar vorausgesetzt. Die Entscheidung für oder wider eines der beiden Frameworks ist im Endeffekt, wie so Vieles, reine Geschmackssache. Viele Onlinediskussionen und Blogeinträge zu diesem Thema können bei der Entscheidung helfen.

Let’s migrate

Es ist grundsätzlich möglich, schrittweise und somit risikoärmer zu einer SPA zu migrieren (Chicken Little Strategy). Sowohl Action-basierte Frameworks wie Spring MVC als auch komponentenbasierte Frameworks wie JSF erlauben die Integration und den Parallelbetrieb einer SPA. Datenbank, Datenmodell und Services sind dann von beiden Welten gleichzeitig zu nutzen. So können schrittweise einzelne Seiten in die SPA-Welt portiert werden – die gesamte Anwendung bleibt aber stets bedienbar.

Ein wesentlicher Vorteil dieses Vorgehens: Es wird frühzeitig Benutzerfeedback eingeholt und man kann auf technologische Schwierigkeiten reagieren. Abbildung 1 zeigt das grobe Vorgehen einer schrittweisen Migration. Wichtig ist es, dass stets von der SPA zurück in die alte Welt – und natürlich umgekehrt – navigiert werden kann. Es hat sich bewährt, die Migration mit den wenig komplexen Seiten zu beginnen. Anfänglich fällt nämlich meist viel Grundlagenarbeit an, die von der eigentlichen Migration ablenkt. Zudem entwickeln sich Patterns und Best Practices im Projekt oftmals erst im Laufe der Zeit – und Refactorings lassen sich später natürlich besser auf einer weniger komplexen Codebasis durchführen. Trotzdem müssen aufwendige Features und Anwendungsfälle frühzeitig migriert werden, um etwaige kritische Pfade aufzudecken.

Abb. 1: Schrittweise Migration zur SPA

Was kann man wiederverwenden?

Geht die Migration von einem Action-basierten Framework wie Spring MVC aus, können die Methoden der Controller, die auch vorher als reine Datenlieferanden agiert haben, häufig fast unverändert weiter genutzt werden. Bei einer Migration von JSF gilt die Faustregel: Was vorher eine Komponente war, ist auch in einer SPA eine Komponente. Die meisten der SPA-Frameworks arbeiten nämlich ebenfalls komponentenbasiert. Häufig lassen sich zudem auch CSS-Styles eins zu eins in der SPA verwenden, auch wenn gerade hier ein komplettes Refactoring häufig Vorteile bringt. Weiterhin lässt sich grundsätzlich jegliche Controller- bzw. Bean-Logik, die den Status des UI widerspiegelt, fast unverändert migrieren. Dazu gehören z. B. sowohl einfache Logiken (z. B. „ist ein Dialog geöffnet?“) als auch komplexere Workflows, wie sie in einem Wizard zu finden sind. Bei einer schrittweisen Migration sind zudem Security-Mechanismen (Log-ins, Sessions-IDs) weiterhin verwendbar, weil die SPA und die klassische Webanwendung in diesem Szenario in der gleichen Session ausgeführt werden können.

Fazit

Die Migration von einer serverseitig gerenderten Webanwendung hin zu einer SPA birgt viele Potenziale. Vor allem die Benutzer können durch bessere Interaktionsmöglichkeiten und geringere Netzwerklasten profitieren. Zudem ist eine Modernisierung der Anwendungen durch den Einsatz neuer Techniken möglich, beispielsweise WebSockets oder clientseitige Speichermöglichkeiten. Trotzdem muss unbedingt geprüft werden, ob die Migration zu einer SPA für die eigene Anwendung überhaupt einen Mehrwert bringt.

Häufig eignen sich die klassischen, serverseitigen Ansätze nämlich besser. Schließlich lassen sich auch mit ihnen moderne Webanwendungen entwickeln (z. B. mit PrimeFaces). Vor der Migration muss nicht nur ein passendes JavaScript-Framework gefunden, sondern es müssen auch wichtige Entscheidungen über die HTTP-Schnittstelle getroffen werden. Es empfiehlt sich, einen Parallelbetrieb der alten und neuen Webanwendung anzustreben, um eine schrittweise Migration zu vollziehen und mit möglichst geringem Risiko zu agieren.

Natürlich ist die Einführung einer SPA ein großer technologischer und häufig auch architektonischer Sprung. Verglichen mit anderen Migrationen ist das Risiko mithilfe des richtigen Vorgehens aber definitiv beherrschbar. In diesem Sinne: Stay tuned!

Mehr zum Thema:

Vier Fragen, die Sie sich bei jedem Webprojekt stellen sollten

Geschrieben von
Sven Kölpin
Sven Kölpin
Sven Kölpin ist Enterprise Developer bei der open knowledge GmbH in Oldenburg. Sein Schwerpunkt liegt auf der Entwicklung webbasierter Enterprise-Lösungen mittels Java EE.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.