SCAYLE eigenes Frontend anbinden: Managed statt Fork

SCAYLE lädt Commerce-Teams explizit ein, das eigene Frontend anzubinden. Auf der Plattform-Seite heißt es sinngemäß: Nutzt unsere APIs, baut euer eigenes Storefront-Frontend, wir liefern euch dafür ein Nuxt-3-Boilerplate und das @scayle/storefront-nuxt-SDK als Startpunkt. Das ist ein ehrliches Angebot, kein Marketing-Trick, SCAYLE positioniert sich bewusst als Backend, nicht als Frontend-Anbieter. Die Frage, die in Sales-Gesprächen seltener gestellt wird: Wer pflegt dieses Frontend eigentlich in Monat 13, wenn das nächste SDK-Major-Release ansteht, oder wenn Marketing die dritte Kampagnen-Seite dieser Woche braucht?

Die Einladung: Nuxt-Boilerplate + @scayle/storefront-nuxt SDK

Wer mit SCAYLE startet, bekommt Zugriff auf ein öffentliches Storefront-Boilerplate: eine Nuxt-3-/Vue-3-Basis mit dem @scayle/storefront-nuxt-Paket, das Composables für Produkt-, Warenkorb- und Checkout-Daten mitbringt. Der Gedanke dahinter ist konsequent, forkt das Repository, macht es zu eurem Code, baut darauf eure eigene Storefront-Logik.

Für ein Entwicklerteam mit freien Kapazitäten ist das eine solide Ausgangsbasis: TypeScript-Typen für SCAYLE-Entitäten, eine Referenzimplementierung für PDP, PLP und Checkout, ein SDK, das direkt gegen die SCAYLE-API spricht. Kein Reverse-Engineering der API-Struktur nötig, kein Custom-Glue-Code für die Grundfunktionen. Für Teams, die Composable-Architektur ohnehin selbst orchestrieren wollen, ist das eine faire Einladung.

Was der Fork tatsächlich kostet

Der Boilerplate-Weg hat einen Haken, den erst der laufende Betrieb sichtbar macht: Ab dem Moment des Forks gehört euch der komplette Wartungsaufwand, dauerhaft.

• Nuxt-Minor- und Major-Updates müssen manuell nachgezogen werden
• SDK-Versionssprünge von @scayle/storefront-nuxt bedeuten Breaking-Change-Reviews im eigenen Code
• Sicherheits-Patches der Node-Dependencies landen in eurem Backlog, nicht bei SCAYLE
• Jede neue Kampagnen-Seite braucht einen Pull-Request, jede Banner-Änderung ein Deployment
• Marketing kann im Storefront nichts selbst anfassen, weil es keinen Editor gibt, nur Code
• Marktplatz- oder Storefront-Features, die SCAYLE nach eurem Fork-Zeitpunkt veröffentlicht, müsst ihr manuell nachbauen, statt sie automatisch zu erhalten

Das ist kein SCAYLE-spezifisches Problem, jeder Bring-your-own-frontend-Ansatz hat diese Eigenschaft eingebaut. Es lohnt sich trotzdem, die Kosten ehrlich einzupreisen, bevor der Fork zum Repository mit dem größten technischen Schuldenberg im Unternehmen wird.

Laioutr als Managed-Antwort auf die SCAYLE-Einladung

Laioutr beantwortet genau diese Einladung, nur managed. Unser Composable Headless Frontend läuft selbst auf einer Nuxt-Foundation, SCAYLE-Teams finden hier also keinen Framework-Bruch. Der Unterschied liegt in der Betriebsebene: Statt einen Fork zu pflegen, verbindet ihr SCAYLE über unseren Orchestr-Datenlayer mit dem Frontend. Produkt-, Bestand-, Kategorie- und Order-Daten fließen normalisiert in unser Component-Schema, dieselben Datenpunkte, die auch das offizielle SDK abbildet, nur ohne dass euer Team die Anbindung selbst pflegt.

Damit übernehmt ihr die SCAYLE-Einladung „bringt euer eigenes Frontend", ohne dass euer Team das Frontend zusätzlich als eigenes Betriebssystem führen muss. Das Ergebnis ist ein Frontend as a Service: CI/CD, Hosting, Framework-Updates und Sicherheits-Patches sind Plattform-Aufgabe, nicht Sprint-Aufgabe eures Teams. Entwicklerinnen und Entwickler behalten vollen Zugriff auf die Komponenten-Ebene, nur ohne die Fork-Instandhaltung im Nacken.

Wie die technische Anbindung aussieht

Technisch bleibt der Ablauf nah an dem, was das SCAYLE-SDK ohnehin vorsieht. Der Orchestr-Layer spricht die SCAYLE-Storefront-API über GraphQL an, holt Produktdaten, Preise, Verfügbarkeiten und Warenkorb-Status und bildet sie auf unser einheitliches Component-Schema ab. PDP-, PLP- und Checkout-Components im Frontend erwarten dieselbe Datenstruktur, unabhängig davon, ob dahinter SCAYLE, Shopware oder commercetools steht, das ist derselbe Vorteil, den auch unsere Decoupling-Story auf der Backend-Seite trägt. Wer heute mit SCAYLE startet und in drei Jahren evaluiert, ob ein zweites Backend dazukommt, muss das Frontend dafür nicht neu bauen.

Für Entwicklerteams heißt das konkret: Ihr bindet SCAYLE-spezifische Felder, zum Beispiel Loyalty-Punkte, individuelle Preisregeln oder Marktplatz-Angebote, über Custom-Resolver im Orchestr-Layer an, statt sie im SDK-Fork nachzubauen. Die Grundfunktionen, Produktkatalog, Warenkorb, Checkout, Bestellungen, sind bereits als Component vorhanden und müssen nicht aus dem SCAYLE-SDK neu abgeleitet werden.

Wer macht was: Entwicklung und Marketing

Der Rollen-Split bleibt klar getrennt. Entwicklerteams definieren Components, binden SCAYLE-spezifische Datenpunkte über den Orchestr-Layer an und erweitern die Komponenten-Bibliothek um eure Besonderheiten, Rabatt-Logik, B2B-Preisstaffeln, individuelle Checkout-Schritte, was auch immer euer Setup braucht. Marketing arbeitet parallel im Studio-Editor, komponiert Kampagnen-Seiten, tauscht Banner, startet Landingpages, alles ohne Pull-Request und ohne auf ein Deployment-Fenster zu warten. Ein konkretes Beispiel: Wenn SCAYLE ein neues API-Feld für B2B-Sonderpreise ausliefert, bindet ein Entwicklerteam es einmal im Orchestr-Layer an, und die Komponente steht danach allen Storefronts zur Verfügung, die sie nutzen, ohne dass Marketing auf einen zweiten Sprint warten muss.

Bei einem geforkten Boilerplate liegt diese Trennung nicht vor, jede Änderung läuft über Code, unabhängig davon, ob sie inhaltlich oder strukturell ist. Für Teams mit hohem Kampagnen-Takt, saisonalen Kollektionen oder häufigen Preis- und Promo-Wechseln ist das der spürbarste Unterschied im Alltag.

Entscheidungsraster: Fork, Managed oder Custom-Build

Drei Situationen, drei sinnvolle Antworten.

Ihr habt ein eigenes, gut besetztes Frontend-Team und wollt volle Pixel-Kontrolle ab Tag eins, ohne Plattform-Layer dazwischen. Dann ist der SCAYLE-Boilerplate-Fork die direkte Antwort, mit dem Wartungsaufwand als bewusst eingegangenem Trade-off.

Ihr wollt die Zeit bis zum Launch verkürzen, und Marketing soll Kampagnen-Seiten selbst bauen können, ohne dass Entwicklerressourcen dafür dauerhaft gebunden sind. Dann ist Laioutr als Managed-Frontend-Layer über SCAYLE der direkte Weg, kalkulierbar im Aufwand, ohne dass ihr SCAYLE als Backend wechseln müsst.

Ihr vergleicht gerade grundsätzlich, welche Frontend-Option zu eurem SCAYLE-Setup passt: Boilerplate, Managed-Plattform oder ein komplett kundenspezifischer Build von Grund auf. Die Gesamtübersicht mit allen Optionen im Detail haben wir in SCAYLE Headless-Optionen im Vergleich gegenübergestellt. Dieser Artikel hier vertieft gezielt die Bring-your-own-frontend-Einladung und was die Managed-Alternative dazu konkret bedeutet.

Fazit

SCAYLEs Einladung „connect your own frontend" ist ein faires Angebot, für Teams mit dauerhafter Kapazität für Frontend-Pflege. Für alle anderen ist Laioutr die Möglichkeit, dieselbe Einladung anzunehmen: SCAYLE als Backend behalten, den Nuxt-Stack nutzen, aber SDK-Wartung, Deploy-Pipeline und Marketing-Fähigkeit an eine Frontend Management Platform abgeben, die genau dafür gebaut ist. Der erste Schritt ist meist ein technischer Discovery-Call, in dem wir gemeinsam klären, welche SCAYLE-Datenpunkte euer Storefront heute braucht. Mehr zur SCAYLE-Anbindung im Detail: Headless Frontend für SCAYLE.