Einen Produktkonfigurator in eine Magento-Storefront einbauen, ohne das Frontend aufzublähenEinen Pr…
Die 5 Schichten eines Frontend as a Service: Studio, Storefront, Connect, Cloud, Agents
Die 5 Schichten eines Frontend as a Service: Studio, Storefront, Connect, Cloud, Agents
Wenn Teams über Frontend as a Service sprechen, landen sie meistens schnell bei einer Feature-Liste: Editor, Hosting, Integrationen, KI-Funktionen. Das verfehlt den eigentlichen Punkt. Frontend as a Service ist kein Bundle, sondern eine Architektur mit fünf klar getrennten Schichten, die jeweils ein eigenes Problem lösen und an einer definierten Grenze an die nächste Schicht übergeben. Wer diese Grenzen nicht kennt, kauft am Ende entweder zu viel Plattform für zu wenig Bedarf oder baut die fehlende Schicht später mühsam selbst nach. Dieser Beitrag zieht die Trennlinien sauber, Schicht für Schicht.
Studio: wo Layout entsteht, nicht wo es gerendert wird
Studio ist die Autoring-Schicht. Hier entstehen Seiten, Komponenten und Kampagnen-Varianten, visuell im Composable Visual Page Builder. Die Grenze zur Storefront-Schicht ist wichtig: Studio produziert Struktur und Content, es rendert nicht selbst an den Endnutzer aus. Ein Marketer baut in Studio eine neue Kampagnen-Landingpage, ohne dass ein Developer-Ticket entsteht, aber die Seite, die am Ende im Browser ankommt, ist ein Ergebnis der Storefront-Schicht, nicht von Studio direkt. Diese Trennung verhindert, dass jede Content-Änderung einen Build-Prozess auslöst, und sie ist der Grund, warum Editing in Echtzeit auf der Live-Seite möglich ist, statt in einem separaten Preview-System zu leben.
Storefront: Rendering, Performance, Auslieferung an den Browser
Die Storefront-Schicht nimmt das, was in Studio komponiert wurde, und rendert es aus, mit Rücksicht auf Core Web Vitals, SEO-Struktur und Barrierefreiheit. Hier wird entschieden, was serverseitig gerendert wird, was am Edge gecacht wird und wie schnell ein Produkt-Listing bei hoher Katalogtiefe lädt. Die Grenze zu Studio ist die Autoring-versus-Runtime-Trennung von oben. Die Grenze zu Connect ist ebenso wichtig: Storefront kennt keine Backend-Details. Sie konsumiert Daten aus definierten Schnittstellen, sie spricht nicht selbst mit dem ERP oder dem PIM. Das hält die Rendering-Schicht austauschbar, unabhängig davon, welches Commerce-Backend im Hintergrund läuft.
Connect: die Integrationsschicht zwischen Frontend und Backend-Landschaft
Connect ist die Schicht, die Daten aus Shopify, Shopware, commercetools, einem PIM, ERP oder OMS in ein Format übersetzt, das die Storefront-Schicht direkt konsumieren kann. Das ist die Schicht, die in vielen Eigenbau-Projekten am Ende zum größten Wartungsposten wird, weil jede neue Integration wieder Custom-Glue-Code bedeutet. In einem sauberen Frontend-as-a-Service-Modell ist Connect orchestriert, nicht ad hoc verdrahtet: eine definierte Integrationsschicht statt einer wachsenden Zahl an Punkt-zu-Punkt-Verbindungen. Die Grenze nach oben zur Storefront ist die Daten-Vertrags-Grenze: Connect liefert normalisierte Daten, Storefront kümmert sich nicht mehr darum, aus welchem System sie kamen. Die Grenze nach unten ist die Backend-Grenze: Connect übernimmt keine Business-Logik der Backend-Systeme, sie bleibt dort, wo sie hingehört.
Cloud: Betrieb, Ausspielung, globale Performance
Cloud ist die Betriebsschicht darunter, verantwortlich für Hosting, Edge-Delivery und Media-Ausspielung, etwa über Edge Hosting oder einen dedizierten Image CDN für Produktbilder. Die Grenze zu Storefront ist funktional: Storefront entscheidet, was gerendert wird, Cloud sorgt dafür, dass es weltweit schnell ankommt, unabhängig von Traffic-Spitzen oder Standort der Nutzerin. Ein Team, das eine eigene Storefront-Anwendung selbst betreibt, übernimmt diese Schicht faktisch mit, meist ohne die dedizierte Erfahrung dafür. Das ist einer der Punkte, an denen der Unterschied zwischen einem selbst gehosteten Headless-Setup und einem echten Frontend-as-a-Service-Betrieb am deutlichsten wird.
Agents: die KI-Schicht über allen anderen vier
Agents sitzt quer über den anderen vier Schichten und automatisiert Aufgaben, die sonst manuell in Studio, Storefront, Connect oder Cloud anfallen würden: Layout-Vorschläge im Editor, Content-Anpassungen über den Content Agent, SEO- und GEO-Optimierung über den SEO/GEO Agent. Wichtig ist die Grenze nach unten: Agents ersetzen keine der anderen vier Schichten, sie bedienen sie. Ein Agent, der eine Landingpage-Variante vorschlägt, arbeitet in der Studio-Schicht, ein Agent, der Bildkompression optimiert, wirkt in der Cloud-Schicht. Ohne die sauber getrennten vier Basis-Schichten hätte die Agents-Schicht keine stabile Grundlage, auf der sie operieren kann. Das ist der Kern der Agentic Frontend Management Platform: KI-Funktionalität, die auf einer bereits sauber geschichteten Architektur aufsetzt, statt Unordnung mit noch mehr Automatisierung zu überdecken.
Unsere Einschätzung
Die meisten Frontend-Probleme, die wir bei Prospects sehen, sind eigentlich Grenz-Probleme: Rendering-Logik, die in die Integrationsschicht durchsickert, Business-Logik, die im Frontend landet, weil die Connect-Schicht fehlt, oder Betriebsverantwortung, die ein Marketing-Team nie übernehmen wollte. Wer Frontend as a Service als reine Feature-Sammlung einkauft, übersieht diesen Punkt und wundert sich später, warum die Wartung trotzdem beim eigenen Team hängen bleibt. Die fünf Schichten sind kein Marketing-Diagramm, sie sind eine Antwort auf die Frage, wer im Betrieb wofür zuständig ist, und diese Antwort muss vor dem Kauf klar sein, nicht danach.
Häufige Fragen
Muss ich alle fünf Schichten gleichzeitig nutzen?
Nein. Viele Teams starten mit Storefront und Connect für ein bestehendes Backend und erweitern später um Studio für Marketing-Autonomie oder um Agents für Automatisierung. Die Schichten sind unabhängig nutzbar, aber sie greifen ineinander, wenn alle fünf im Einsatz sind.
Wo verläuft die Grenze zwischen Studio und einem klassischen CMS?
Ein klassisches CMS verwaltet Content, meist getrennt vom Rendering. Studio ist eng an die Storefront-Rendering-Schicht gekoppelt, Änderungen erscheinen direkt in der Live-Seite, nicht über einen separaten Preview-Build.
Ersetzt die Cloud-Schicht mein bestehendes Hosting?
Wenn ihr die Storefront-Schicht bei Laioutr betreibt, ja. Backend-Hosting für ERP, PIM oder Commerce-Engine bleibt unberührt, das ist außerhalb der fünf Frontend-Schichten.
Was unterscheidet Agents von klassischer Personalisierung?
Personalisierung passt Inhalte pro Nutzer an, meist innerhalb der Storefront-Schicht. Agents automatisieren Aufgaben quer über alle Schichten hinweg, inklusive Layout-Vorschlägen und SEO-Arbeit, die sonst ein Mensch manuell erledigen würde.
Nächste Schritte
Wenn ihr klären wollt, welche der fünf Schichten für euren Stack heute den größten Unterschied macht, buche eine 30-Minuten-Demo und wir zeigen die Architektur an eurem konkreten Setup.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich täglich mit der Frage, wie Commerce-Teams Frontend-Verantwortung sauber schneiden, ohne Backend-Investitionen zu gefährden.