Headless Commerce – Eine Erklärung
„Headless“ ist ein Begriff aus der IT Architektur und zeichnet sich dadurch aus, das Daten und Geschäftslogik (Backend) konsequent von der Darstellung (Frontend) getrennt sind.
Das Ergebnis sind Komponenten, die möglichst unabhängig voneinander funktionieren. Für die Kommunikation werden Schnittstellen (APIs) genutzt, über die die Komponenten miteinander verbunden werden.
Doch warum will man so etwas eigentlich? Schauen wir zunächst auf den „traditionellen“ Ansatz.
Die alte Welt = Alles aus einem Shop
Bei bisherigen Lösungsansätzen sind Front- und Backend oft fest miteinander verbunden. Werden z.B. im Backend Daten gepflegt, können sie im Frontend sofort angezeigt werden. Bei diesem Ansatz ist dieselbe Software für das Speichern, Verarbeiten und Anzeigen verantwortlich. Auf der einen Seite ist das praktisch, aber es beschränkt den Funktionsumfang auch auf diese Software und auf die integrierten Drittsysteme.
Problematisch ist bei diesem Ansatz nämlich, dass Funktionserweiterungen für jeden Shop entwickelt werden müssen. Wer kennt nicht die Situation, dass genau das benötigte Modul für den aktuellen Shop nicht oder noch nicht zur Verfügung steht. Funktionserweiterungen müssen beim „traditionellen“ Ansatz eben pro Shopsystem entwickelt werden. Auch ist eine Migration zu einem neuen Shopsystem i.d.R. mit erheblichem Aufwand verbunden, da alle Funktionserweiterungen neu entwickelt werden müssen.
Die neue Welt – Lasst Headless Commerce Komponenten sprechen
Anders funktioniert der Headless Ansatz. Hier werden Funktionsbausteine von vorneherein als eigenständige Komponenten verstanden, die über eine Frontendtechnologie miteinander verknüpft werden. Suche, Checkout und Produktdarstellung können so von unterschiedlichen Anbietern stammen.
Auch ist der Austausch von Funktionsbausteinen entsprechend einfach, da nur die Schnittstellen kompatibel bleiben müssen.
Zur Optimierung Ihrer Suche und Checkoutprozesse empfehlen folgende Blogbeiträge:
Headless Commerce oder nicht – was bleibt nach dem Vergleich?
Statt einer starren Systemarchitektur verspricht Headless mehr Flexibilität und vor allem den einfachen Rollout von digitalen Vertriebsprozessen an die unterschiedlichsten Orte und die unterschiedlichsten Technologien durch den Einsatz von Komponenten.
Im eCommerce erfolgt der Verkauf nämlich häufig über immer mehr Kanäle, die sich im Benutzererlebnis stark voneinander unterscheiden. Als Beispiel seien hier Voice Commerce, Smartwatches und Augmented Reality genannt. Um alle diese Kanäle zu bedienen, gibt es keine allumfassende Softwarelösung.
Hinzu kommt, dass viele Firmen dazu übergehen auch eine immer gezieltere Ansprache einzelner Kundengruppen vorzunehmen, um sich gegenüber der wachsenden Konkurrenz durchzusetzen. Somit werden einzelne Frontends nicht nur für die unterschiedlichen Kanäle, sondern sogar für einzelne Kundengruppen entwickelt.
In der Flexibilität solche Szenarien effizient zu bedienen, liegt der große Vorteil von Headless Commerce. Mit Headless Commerce kann man in Form von Microservices schnell neue Vertriebskanäle aufsetzen und testen. Dadurch ergibt sich ein klarer Wettbewerbsvorteil, da man schneller und effizienter ist und bei neuen Entwicklungen als einer der Ersten von deren Vorteilen profitieren kann.
Zum Beispiel ist ein Checkout-Prozess ein immer sehr ähnlich ablaufender Vorgang. Wird dieser einmal als Headless Prozess aufgebaut, kann er einfach durch Integration in plattformoptimierte Umgebungen mehrfach standardisiert genutzt werden. Diese Vorteile gelten auch für alle anderen typischen Commerce Prozesse, wie Login, Preisermittlung, etc.
Und gibt es auch Nachteile von Headless Commerce?
Ja, die Komplexitäten, die sich zwischen einzelnen Funktionsbausteinen bei Headless Commerce ergeben, bleiben natürlich bestehen. Wenn sich ein Kunde einloggt, muss nicht nur das Frontend über den Kundennamen für die persönliche Begrüßung informiert werden, auch der Checkout (Bestellbestätigungsseite optimieren) sollte vorhandene Rechnungs- und Lieferadressen kennen.
Um das effizient umzusetzen ist eine gute Planung und Architektur erforderlich, denn beim Headless Ansatz kennen die Funktionsbausteine sich i.d.R. nicht.
Ergänzend kommt ein Versionsproblem hinzu, welches das folgende Schaubild verdeutlicht.
Zu Anfang eines Projektes sind die Komponenten noch klar definiert, abgegrenzt und funktionell getrennt, aber nach dem ersten Release kommen i.d.R. schnell Anpassungen und neue Anforderung, die berücksichtigt werden müssen. Dies führt im schlimmsten Fall irgendwann zu Inkompatibilitäten zwischen den einzelnen Komponenten, die dann mühsam aufgelöst werden müssen. Dies gilt insbesondere da ja einer der Vorteile von Headless der einfache, plattformübergreifende Einsatz ist.
Wie bekommt man diese Nachteile von Headless Commerce in den Griff?
Grundsätzlich sollten Headless Commerce Projekte auf die richtige Technologie setzen. Dies ist für uns im Backend GraphQL. GraphQL ist nicht nur viel flexiblere und Versionskonflikt resistenter als zum Beispiel der Einsatz eines Rest APIs. Schauen wir uns dazu ein kleines Beispiel an.
Wir möchten über Rest API die Mitarbeiter eines Unternehmens und die Abteilungen in denen sie arbeiten ermitteln.
Dazu schauen wir uns die Abläufe mit Rest API und GraphQL im Vergleich an.
Rest API Beispiel
Beim Rest API fällt auf, dass man zwei Abfragen benötigt. Des Weiteren fällt auf, dass man die Funktionen auf dem Server sehr genau kennen muss. Umgekehrt bedeutet dies auch, dass man jede Änderung an den Serverfunktionen auch im Client nachvollziehen muss. Hier lauert schnell das oben dargestellt Versionsproblem.Schauen wir uns um Vergleich dazu den gleichen Aufruf mit GraphQL an.
GraphQL – Beispiel
Der wesentliche Unterschiede ist, dass bei GraphQL nicht Funktionsparameter zum Einsatz kommen, sondern dass eine Abfrage übertragen wird. Diese ist sehr viel änderungsresistenter, da z.B. Feld oder Relationserweiterungen durchgeführt werden können, ohne das jeweils alle Abfragen angepasst werden müssen. Ggfs. können auch Versionsinformationen Teil der Abfrage werden. Das macht GraphQL im Vergleich zu Rest API eindeutig überlegen.
Wer unterstützt heute bereits GraphQL?
Hier sind aktuell die folgenden eCommerce Systeme verfügbar:
Und was ist für das Frontend wichtig?
Hier ist die Technologieentscheidung nicht ganz so wesentlich. Die drei am meisten eingesetzten Frontendtechnologien für Headless Commerce sind:
Angular hat eine eher monolitische Architektur, die möglichst viel Funktionalität und damit auch Komplexität in sich vereint. Hat aber den Ruf überladen und kompliziert zu sein.
React kann man sowohl in vorhandenen HTML Projekten nutzen, als auch als für neue Projekte, ist allerdings eher eine Bibliothek als ein Framework.
Vue.JS wird am besten vom Erfinder Evan You, Erfinder mit den Worten: „I figured, what if I could just extract the part that I really liked about Angular and build something really lightweight.“ beschrieben.
Es kann genauso wie React direkt in eine vorhandenes HTML eingebunden werden.
Aus unserer Sicht ist die beste Technologie für das Frontend Vue.JS. Hierüber ließen sich aber Bücher schreiben.
Fazit
Die deutlich höhere Flexibilität im Frontend wird dafür sorgen, dass sich Headless Commerce durchsetzt. Alle namhaften Webshop- und eCommerce Anbieter arbeiten bereits an Headless Commerce. Wer heute eine neue Implementierung startet, sollte sich deshalb gut überlegen, ob nicht von vorne herein ein Headless Commerce Ansatz gewählt werden sollte.
Erfahren mehr über Produktdaten und PIM sowie Digitale Vertriebsprozesse in unseren spannenden Podcasts:
