SAP Spartacus: Progressive Web Applications

Interview mit Fabian Saccilotto, valantic CEC Schweiz

Spartacus ist eine Angular-basierte JavaScript-Lösung, die hauptsächlich im Browser läuft. Sie zählt zu den Progressiven Web Applications (PWA), die wiederum eine Symbiose aus einer responsiven Website und einer App darstellen. Was genau bedeutet das, und welche Vor- und Nachteile bringt SAP Spartacus mit sich? Diese und weitere Fragen hat uns Fabian Saccilotto von valantic CEC Schweiz im Interview gerne beantwortet.

Was sind die Unterschiede zwischen Progressiven Web-Apps (PWA), nativen Apps und dem Zugriff über Standard-Browser? Was sind die Vor- und Nachteile?

Beginnen wir mit der üblichen Zugriffart – dem „normalen Zugriff“ auf eine vom Server gerenderte HTML-Seite per Browser: Fragt der Browser eine Seite ab, so liefert der Server die entsprechende HTML-Seite mit etwaigen Stylesheets (CSS) und JavaScript. Nach Erhalt der Inhalte wird die komplette Seite vom Browser dargestellt und allfälliges JavaScript ausgeführt. Jede Navigation innerhalb der Seite führt zu einem Neuladen der gesamten Inhalte.

Native Apps sind vom Aufbau her grundsätzlich anders als Webpages. Sie werden üblicherweise mit geräteabhängigen Frameworks implementiert (Android oder Swift für iOS) und haben als Basis ein Betriebssystem auf dem Endgerät. Apps kommunizieren üblicherweise mit einem Backend über API-Schnittstellen, um Daten nachzuladen und in ihrem Speicher abzulegen.

Für den Kunden bedeutet die Umsetzung einer nativen App, dass nebst einer Website eine separate Applikation für Geräte entwickelt werden muss. Es kann also nicht derselbe Code verwendet werden. Native Apps bieten dem User auf mobilen Geräten jedoch das beste Nutzererlebnis. Sie können gut offlinefähig gebaut werden und bieten vollständigen Zugriff auf Gerätefunktionen wie GPS, Kamera etc.

Single Page Applications (SPA) oder auch ihre Erweiterung (PWA) hingegen sind immer noch Webpages. Im Gegensatz zum üblichen Zugriff besteht die Seite praktisch nur aus JavaScript und – wie der Name sagt – einer einzelnen HTML-Seite.

Der Server liefert also bei der ersten Anfrage des Browsers im Prinzip immer dieselbe Seite aus. Das meist etwas umfangreichere JavaScript stellt daraufhin die Inhalte dar und tauscht die Elemente auf der Seite dynamisch aus. Sprich: Nur die erforderlichen Daten werden nachträglich vom Server geladen – je nachdem, welche URL und somit welche Daten der Benutzer angefordert hat. Alles, was bereits einmal vom Server abgefragt wurde, wird lokal zwischengespeichert und ist bei erneuter Verwendung direkt vorhanden.

Eine solche Applikation fühlt sich für den Benutzer viel flüssiger an, da ein Neuladen der Seite ausbleibt. Zudem kann sehr gezielt gesteuert werden, welche Daten geladen werden müssen. PWA können oft auch auf verschiedene Gerätefunktionen zugreifen. Der intensive Einsatz von JavaScript ist für Suchmaschinen und ältere Geräte jedoch eine Hürde. Daher kommt häufig Server Side Rendering zum Einsatz: Das JavaScript wird auf dem Server in HTML umgewandelt und wie bei der üblichen Zugriffsart ausgespielt. Sobald jedoch die Seite geladen ist, erfolgen alle Zugriffe wiederum ohne Neuladen der Seite.

Eine PWA muss vom Shop-Kunden auch erst einmal installiert werden. Ist das nicht eine zusätzliche Hürde gegenüber E-commerce-Shops, auf die ich ohne App über einen normalen Standard-Browser zugreifen kann? Ich als Kunde fände das bequemer.

Eine PWA ist in erster Linie eine Website und muss nicht installiert werden. Sie kann aber wie eine App als Icon auf dem Gerät abgespeichert werden. Aufgrund ihrer Webseiten-Natur muss sie im Gegensatz zu klassischen Apps nicht aktualisiert werden.

Der Zugriff über native Apps ist mittlerweile schon ein Auslaufmodell, oder?

Das kommt auf den jeweiligen Anwendungsfall an. Für viele Unternehmen ist die Entwicklung von zusätzlichen nativen Apps – für Android, iOS, Windows plus verschiedene Geräteversionen – jedoch ein zu großer finanzieller und organisatorischer Aufwand.

Welche Vorteile bieten PWA für SAP-Commerce-Unternehmenskunden ganz konkret?

Das SAP-Commerce-System wird headless betrieben, was den Zugriff von anderen Systemen erleichtert. Mit PWA können Inhalte sehr spezifisch nachgeladen werden, wodurch die Performance besser bewertet wird, auch von Google. Es ist nur eine Applikation für Website und Geräte nötig. Zudem kommen neuere Frontend Frameworks zum Einsatz, was die Attraktivität bei Mitarbeiter*innen steigert.

Mehr zum Thema Headless Commerce erfahren!

Welche Vorteile bieten PWA für Endkunden?

Die Vorteile von PWA für Endkunden sind ganz klar: ein flüssigeres und schnelleres Benutzererlebnis und je nach Umsetzung auch eine bessere Anpassung der Oberfläche an die Gerätegröße.

Wie aufwendig ist die Migration von Accelerators zu PWA? Mit welchen Zeit- und Kostenaufwendungen muss ich rechnen?

Das ist sehr unterschiedlich, je nach Ausgangslage. Der Aufwand hängt jedoch nicht von der Anzahl der Artikel, sondern eher von der bestehenden Code-Struktur wie auch vom Seitenaufbau und dessen Komplexität ab.

Wie sicher ist AngularJS?

Bei einer PWA, SPA und bei modernen Frameworks gelten grundsätzlich dieselben Sicherheitsaspekte wie bei einer herkömmlichen Website. AngularJS und andere Frameworks bieten jedoch Funktionalitäten an, welche die Implementierung dieser Aspekte erleichtern. Die Sicherheit muss allerdings auf dem Server genauso sichergestellt werden – und es dürfen keine sensitiven Daten innerhalb des Clients gespeichert werden.

Was bedeutet der Einsatz von Spartacus für SAP-Commerce-Kunden?

Aufgrund der wesentlich höheren Komplexität einer PWA – was Spartacus ist –braucht es andere und intensivere Kenntnisse in JavaScript und modernen Frontend Frameworks. Wird Server Side Rendering benötigt und SAP Commerce on-premises betrieben? Dann sind beispielsweise zusätzliche Infrastruktur sowie angepasste Entwicklungs- und Deployment-Prozesse nötig.

Was bedeutet dies für meine Upgrade-Strategie? Sollen Neuentwicklungen mit Spartacus umgesetzt werden

Grundsätzlich sollte man sich meiner Meinung nach mit einer Ablösung durch Spartacus auseinandersetzen. Je nach Rahmenbedingungen und Anforderungen kann es aber sein, dass ein anderer Weg eingeschlagen werden sollte.

SAP Spartacus ist relativ jung, und es gibt ein paar Aspekte, die unter Umständen noch zu rudimentär gelöst wurden. Einige Dinge wie Server Side Rendering sind zu beachten. Vor allem, wenn die Migration in die Cloud (noch) nicht vorgenommen werden kann. Bewegt man sich mit seiner Lösung nahe an einem Accelerator oder dem Standard, ist der Umstieg auf Spartacus mit großer Wahrscheinlichkeit sinnvoll.

Was bedeutet der Umstieg auf SAP Spartacus für meine Organisation?

Spartacus basiert auf den Grundsätzen einer PWA (Progressive Web Application) und auf der Technologie AngularJS. Viele Firmen arbeiten im Accelerator mit vergleichsweise einfachem JavaScript auf Basis von JQuery oder ähnlichem. Eine PWA stellt einen erheblichen Komplexitätszuwachs dar, da diese auch klassische Applikationselemente wie Routing, Security, Persistenz und Asynchronität aufweist. Die Frontend-Entwickler brauchen also wesentlich bessere Fähigkeiten in JavaScript und in der Applikationsentwicklung.

Auch der Entwicklungsprozess und die Schnittstellen zu SAP Commerce (Hybris) sind andere, was je nach Codequalität Umstrukturierungen benötigt. Wer Spartacus in einer On-Premises-Landschaft betreiben möchte, muss je nach Anforderungen Server Side Rendering und die benötigte Infrastruktur umsetzen. Gleiches gilt auch für den dazugehörigen Deployment-Prozess. In der Cloud bietet SAP bereits Support dafür an.