Integrationen und Erweiterbarkeit

Integrationen und Erweiterbarkeit

0:00 Jede Integration ist ein Versprechen über Jahre. Die API ändert sich vierteljährlich, das angebundene System ändert sich auch — nur eben nicht zur selben Zeit. In diesem Modul geht es deshalb weniger um die Frage, wie man etwas anbindet, als darum, wie man es so anbindet, dass es in zwei Jahren noch läuft. Wir sehen uns Versionierung und Supportfristen an, die definierten Erweiterungspunkte, die Eigenheiten von Webhooks — und was man übernimmt, wenn man sich für Headless entscheidet.

Integrationen und Erweiterbarkeit

0:29 Vier Kapitel. Zuerst die APIs und ihre Versionierung, mit konkreten Fristen, die Planungssicherheit geben. Dann die Erweiterungspunkte — also wo eine App überhaupt ansetzen darf. Danach die Systemintegration mit Webhooks, wo eine Eigenschaft besonders wichtig ist: Zustellung ist nicht garantiert. Und zum Schluss Headless als Entscheidung mit langfristigen Folgen.

0:51 In der Übung zeichnen Sie die Integrationslandkarte von Steglicht — und legen fest, welches System bei welchem Feld führt.

APIs und Versionierung

0:59 Beginnen wir mit dem Fahrplan. Shopify veröffentlicht vierteljährlich, und das ist berechenbarer, als es klingt. Shopify veröffentlicht vierteljährlich eine neue API-Version, jeweils am ersten Tag des Quartals. Die Namen folgen dem Datum — 2026-07 etwa ist die aktuelle Version der GraphQL Admin API zum Stichtag dieses Seminars.

1:20 Und jede stabile Version wird mindestens zwölf Monate unterstützt. Das ist die Zahl, die Planung möglich macht: Sie wissen, wie oft Sie hinsehen müssen, und Sie wissen, wie viel Zeit Sie haben. Das ist bei weitem nicht bei allen Plattformen so klar geregelt. Drei Arten mit drei Verwendungszwecken. Stable ist für den Produktivbetrieb und bleibt über ihre Laufzeit stabil — das ist die einzige, gegen die Sie bauen sollten.

1:46 Release Candidate erscheint zusammen mit dem stabilen Release und kann brechende Änderungen enthalten; sie ist zum Vorbereiten da, nicht zum Betreiben. Und Unstable wird laufend verändert, Funktionen können jederzeit entfallen — sie ist zum Ausprobieren da. Die Fußzeile nennt die Zahl, die im Betrieb zählt: mindestens neun Monate Überlappung zwischen zwei aufeinanderfolgenden Versionen.

2:09 Vier praktische Folgerungen. Abgekündigtes verschwindet erst in einer der nächsten Versionen, nicht sofort. Für eine Migration bleiben damit mindestens neun Monate — genug Zeit, um sie zu planen, zu wenig, um sie zu vergessen. Bei einer zurückgezogenen Version antwortet Shopify mit der ältesten noch erreichbaren stabilen; Ihre Integration bricht also nicht schlagartig ab, sie verhält sich nur plötzlich anders.

2:35 Und ein Detail aus dem letzten Modul: Shopify Flow nutzt seinerseits eine feste Version, zum Stichtag 2026-01. Zwei Stände im selben Shop. Der erste Punkt ist eine Abkürzung mit Ablaufdatum: Eine Integration wird gegen unstable gebaut, weil dort ein benötigtes Feld schon existiert. Das funktioniert — bis es das nicht mehr tut. Der zweite ist ein Organisationsfehler: Niemand verfolgt die Änderungsmeldungen, und die Umstellung wird zur Notoperation.

3:03 Der dritte macht Fehlersuche unnötig mühsam: Die verwendete API-Version ist nicht dokumentiert. Und der vierte ist der stille Ausfall: Eigene Workflows brechen, weil ein Feld aus der Version verschwunden ist — ohne Fehlermeldung, nur mit leerem Ergebnis.

Apps und Extensions

3:19 Weiter mit der Frage, wo eine Erweiterung ansetzen darf. Shopify hat dafür definierte Punkte — und die sind eine gute Nachricht. Erweitert wird an definierten Punkten. Theme App Extensions im Onlineshop, Admin UI und Customer Account Extensions in den jeweiligen Oberflächen, Checkout UI Extensions im Checkout, Shopify Functions für serverseitige Logik und Web Pixels für Ereignisse.

3:43 Diese Liste wirkt lang, ist aber in Wahrheit eine Einschränkung — und zwar eine hilfreiche. Denn sie sagt auch, wo nicht erweitert wird. Wer weiß, welche Punkte existieren, kann eine Anforderung zuordnen, bevor jemand anfängt zu bauen. Vier Schichten, von oben nach unten. Im Onlineshop die Theme App Extensions und App Blocks — sichtbar für die Kundschaft.

4:05 In Admin und Kundenkonto die UI Extensions, also Oberflächen für Ihr Team und für Ihre Kundschaft. Im Checkout die UI Extensions und Shopify Functions, wobei die Functions serverseitig entscheiden. Und ganz unten die Datenschicht: GraphQL Admin API, Storefront API, Webhooks. Der Nutzen des Bildes liegt in der Zuordnung: Eine Anforderung gehört zu genau einer dieser Schichten. Wenn sie zu zweien gehört, sind es zwei Anforderungen.

4:33 Vier Gründe, die sich über die Jahre auszahlen. Erweiterungspunkte überleben Theme-Updates, eingefügter Code nicht zwangsläufig. Sie werden versioniert und über das CDN ausgeliefert — Sie haben also eine definierte Fassung statt eines Standes. Sie lassen sich deinstallieren, ohne Reste zu hinterlassen; erinnern Sie sich an die Codeschnipsel aus dem letzten Modul. Und sie sind dokumentiert und damit von anderen wartbar.

4:58 Der letzte Punkt ist der, der bei Personalwechseln zählt, und Personalwechsel gibt es in jedem Projekt. Der erste Punkt ist die Versuchung der schnellen Sichtbarkeit: Logik wandert ins Theme, weil dort schneller ein Ergebnis zu sehen ist. Der zweite ist die Tarifgrenze, die uns in diesem Seminar mehrfach begegnet ist: Eine eigene App mit Function-APIs wird geplant, und der Shop ist nicht auf Plus.

5:22 Der dritte ist die Reihenfolge, die wir seit Modul eins predigen: Erweiterungen werden gebaut, bevor jemand die Standardfunktion geprüft hat. Und der vierte ist Wildwuchs mit System: Jede Erweiterung bekommt eine eigene App, und die Zahl wächst unkontrolliert.

Systemintegration

5:37 Jetzt zu den Webhooks. Und zu einer Eigenschaft, die jede Integrationsarchitektur bestimmen sollte. Webhooks melden Ereignisse an ein externes System. Abonniert werden sie über die Datei shopify.app.toml oder die GraphQL Admin API, zugestellt an eine URL, einen Google-Pub/Sub-URI oder eine Amazon-EventBridge-ARN. Und jetzt der Satz, den man sich merken muss: Die Zustellung ist ausdrücklich nicht garantiert.

6:04 Das steht so in der Dokumentation, und es ist keine Schwäche, sondern eine ehrliche Aussage über verteilte Systeme. Wer eine Integration baut, die diese Aussage ignoriert, baut auf einer Annahme statt auf einer Zusage. Vier Konsequenzen. Es gibt keine Reihenfolgegarantie, weder innerhalb eines Themas noch über Themen hinweg.

6:25 Konkret heißt das: Ein products/update kann vor dem products/create eintreffen — was im Zielsystem zu einem Datensatz führt, den es noch gar nicht gibt. Die Reihenfolge ergibt sich deshalb aus Zeitstempeln, nicht aus der Zustellung. Und doppelte Zustellungen werden über die Webhook-ID erkannt und verworfen. Diese vier Punkte sind keine Randnotizen — sie sind die Bauanleitung für alles, was danach kommt.

6:50 Fünf Schritte. Legen Sie je Datenobjekt fest, welches System die Führung hat — das ist die fachliche Entscheidung, alles andere ist Technik. Abonnieren Sie die Ereignisse und prüfen Sie die HMAC-Signatur jeder Zustellung; ein offener Endpunkt nimmt sonst alles an, was ankommt. Verwerfen Sie doppelte Zustellungen anhand der Webhook-ID. Richten Sie einen Abgleichlauf ein, der Daten regelmäßig nachzieht.

7:13 Und protokollieren Sie Abweichungen und legen Sie sie jemandem vor. Shopify empfiehlt solche Abgleichläufe ausdrücklich — Webhooks allein halten keine Konsistenz. Der erste Punkt ist der Architekturfehler, den dieses Kapitel verhindern soll: Die Integration verlässt sich auf Webhooks ohne Abgleichlauf. Sie läuft monatelang gut und dann fehlt ein Vorgang. Der zweite ist ein Sicherheitsproblem: Die Signatur wird nicht geprüft, der Endpunkt nimmt alles an.

7:41 Der dritte ist der Dauerbrenner der Systemintegration: Zwei Systeme führen dasselbe Feld, und der letzte Schreiber gewinnt. Und der vierte ist ein Betriebsloch: Fehlgeschlagene Zustellungen werden nirgends sichtbar — niemand weiß, dass etwas fehlt.

Headless und technische Verantwortung

7:56 Zum Abschluss die große Entscheidung. Und die nüchterne Formulierung, die Shopify selbst dafür wählt. Bei einem Headless-Storefront bauen und betreiben Sie das Frontend selbst und nutzen die Commerce-APIs von Shopify. Hydrogen als React-Framework zusammen mit dem Hosting Oxygen ist der kürzeste Weg dorthin. Und Shopify beschreibt Headless wörtlich als die größte Kontrolle und zugleich die meiste Arbeit. Diese Offenheit sollte man würdigen — und ernst nehmen.

8:24 Denn die Arbeit verschwindet nicht dadurch, dass man sie übernimmt. Sie wechselt nur von einer Plattform, die sie täglich macht, zu einem Team, das sie nebenbei machen soll. Vier Zeilen im Vergleich, und sie beschreiben weniger Technik als Arbeitsweise. Links rendert und hostet Shopify, die Redaktion ändert im Editor, Performance ist ab Werk geprüft, und Updates kommen vom Theme.

8:46 Rechts betreiben Sie das Frontend selbst, jede Änderung läuft über ein Release, Performance verantworten Sie, und die Aktualisierung liegt beim Team. Die entscheidende Frage ist deshalb nicht, ob Sie es können — sondern ob Sie es dauerhaft tun wollen. An einem guten Tag kann jedes Team das. Über drei Jahre ist es eine andere Frage.

9:06 Vier Verantwortungen wandern mit. Barrierefreiheit, Performance und SEO werden zur eigenen Aufgabe — also genau die Themen aus Modul sieben und acht, die ein gutes Theme weitgehend mitbringt. Protokollierung und Überwachung des Frontends brauchen einen Betrieb. Jede API-Version verlangt eine Prüfung der eigenen Abfragen.

9:26 Und die Arbeitsteilung der APIs sollte man kennen: Die Storefront API liefert Produkte, Warenkorb und Checkout, die Customer Account API Anmeldung und Bestellungen. Zwei Schnittstellen, zwei Zuständigkeiten, beide dauerhaft zu pflegen. Der erste Punkt ist der folgenreichste: Headless wird gewählt, ohne den Betrieb personell zu planen. Die Entscheidung fällt im Projekt, die Kosten fallen danach an.

9:50 Der zweite trifft die Organisation: Die Redaktion kann nichts mehr selbst ändern und wartet auf jedes Release — das bremst mehr, als die schnellere Seite gewinnt. Der dritte ist ein verdeckter Verlust: Barrierefreiheit fällt heraus, weil das Theme sie vorher mitbrachte. Und der vierte ist eine Planungsfalle: Der Hydrogen-Neubau steht als Developer Preview und wird trotzdem schon eingeplant.

Übung

10:13 Jetzt zeichnen Sie die Landkarte. Und beantworten dabei die Frage, die in Integrationsprojekten am längsten offenbleibt. Bei Steglicht führen drei Systeme Daten: der Shop, ein ERP mit Artikelstamm und Beständen und eine Buchhaltung. Künftig kommt ein CRM für den Geschäftskundenvertrieb dazu — Sie erinnern sich an Federhaus aus Modul fünfzehn. Und heute werden Bestände zweimal gepflegt.

10:37 Dieser letzte Satz ist der eigentliche Auftrag: Doppelte Pflege ist immer ein Symptom fehlender Führungsentscheidung. Irgendwann hat jemand beide Wege gebaut, weil keiner allein zuverlässig war. Das Lernziel: Datenführung zwischen Systemen festlegen und die Folgen eines Ausfalls der Übertragung vorher benennen. Beides gehört zusammen, denn eine Führungsentscheidung ist nur so viel wert wie ihre Fehlerbehandlung.

11:02 Erfolgreich sind Sie, wenn je Datenobjekt führendes System, Richtung, Auslöser und Abgleichweg feststehen — und wenn für zwei Objekte beschrieben ist, woran ein Synchronisationsfehler auffällt. Wer früh fertig ist, ergänzt die betroffene API-Version je Schnittstelle. Genau diese Angabe fehlt in den meisten Landkarten und wird in jedem Störungsfall gesucht.

11:23 Listen Sie zuerst die Datenobjekte auf: Artikel, Preise, Bestände, Kunden, Bestellungen. Bestimmen Sie je Objekt das führende System und begründen Sie die Wahl — die Begründung ist wichtiger als die Wahl, weil sie später überprüfbar ist. Legen Sie Richtung und Auslöser fest: Ereignis oder Abgleichlauf. Beschreiben Sie je Strecke, woran ein Fehler auffällt.

11:45 Und stellen Sie die Landkarte vor, mit der Doppelpflege ausdrücklich markiert. Denn die aufzulösen ist der Nutzen dieser Übung. Der erste Punkt ist der, der Landkarten schönt: Zwei Systeme führen die Bestände, und die Landkarte verschweigt es — weil es unangenehm ist, das aufzuschreiben. Der zweite ist der Architekturfehler aus Kapitel drei: Alle Strecken laufen ereignisbasiert, ein Abgleich fehlt.

12:10 Der dritte ist eine halbe Antwort: Der Fehlerfall wird beschrieben, aber niemandem zugeordnet. Und der vierte ist eine typische Planungsvermischung: Das CRM wird eingezeichnet, obwohl seine Einführung offen ist — und dann plant man um ein System herum, das es noch nicht gibt.