Die Ausgangssituation: E-Commerce unter extremen Bedingungen
Als Condor Airlines uns beauftragt hat, einen digitalen Shop für das Bordportal FlyConnect zu entwickeln, war schnell klar: Das hier ist kein normales Shopify-Projekt.
Die Rahmenbedingungen unterscheiden sich fundamental von einem klassischen Online-Shop. Die Internetverbindung an Bord läuft über Satellit. Wer schonmal WLAN im Flugzeug benutzt hat, kennt die Realität: hohe Latenzen, begrenzte Bandbreite, instabile Verbindungen. Ein klassischer Shopify-Store mit Theme, App-Bloat und Third-Party-Scripts wäre unter diesen Bedingungen schlicht nicht nutzbar gewesen.
Gleichzeitig sollte das Shopping-Erlebnis an Bord sich nahtlos in das bestehende Condor-Ökosystem einfügen. Der Produktkatalog, die Bestandsverwaltung, die Bestellabwicklung - alles sollte über die bestehende Shopify-Infrastruktur laufen. Kein separates System, keine doppelte Datenpflege.
Die Lösung: Eine komplett eigene Storefront, die Shopify headless als Commerce-Engine nutzt, aber in jeder anderen Hinsicht auf die speziellen Anforderungen des In-Flight-Einsatzes optimiert ist.
Warum Headless Shopify hier die einzig richtige Wahl war
In der Shopify-Community wird seit Jahren über Headless diskutiert. Oft zurecht kritisch - für die meisten Shops ist der Overhead einer eigenen Storefront schwer zu rechtfertigen, wenn Shopify Themes und Liquid bereits eine solide Lösung bieten.
Dieses Projekt ist der Gegenfall. Ein Shopify Theme kam aus mehreren Gründen nicht in Frage:
Bandbreite: Ein durchschnittliches Shopify Theme lädt mehrere Megabyte an Assets - JavaScript, CSS, Fonts, Third-Party-Scripts. Über Satelliteninternet mit geteilter Bandbreite für hunderte Passagiere ist das nicht praktikabel. Unsere SPA kommt mit einem Bruchteil dessen aus.
Kontrolle über Requests: Im normalen Shopify-Betrieb macht der Browser dutzende Requests an verschiedene Domains - Shopify CDN, App-Embeds, Analytics-Dienste, Font-Provider. In einer Umgebung mit 500+ ms Latenz pro Request ist jeder einzelne davon spürbar. Wir brauchten volle Kontrolle darüber, welche Requests wann und wohin gehen.
Offline-Fähigkeit: Verbindungsabbrüche sind im Flugzeug keine Ausnahme, sondern die Regel. Der Shop muss auch dann funktional bleiben, wenn die Verbindung für Sekunden oder Minuten wegbricht. Das erfordert clientseitiges State-Management und lokale Datenhaltung - Dinge, die mit Liquid nicht umsetzbar sind.
Der Tech Stack im Detail
Frontend: Solid.js statt React
Die Wahl des Frontend-Frameworks war eine der wichtigsten Entscheidungen im Projekt. Wir haben uns bewusst gegen React und für Solid.js entschieden.
Solid.js bringt eine Bundle-Größe von rund 7KB (gzipped) mit. Zum Vergleich: React + ReactDOM liegen bei ca. 42KB. In einer Umgebung, in der jedes Kilobyte über Satellit transportiert wird, ist das ein relevanter Unterschied.
Entscheidender ist aber das Rendering-Modell. Solid.js arbeitet mit fine-grained Reactivity - es gibt kein Virtual DOM, keinen Diffing-Algorithmus, keine Re-Renders ganzer Komponentenbäume. Wenn sich ein Produktpreis ändert oder ein Artikel in den Warenkorb gelegt wird, aktualisiert Solid.js exakt die betroffenen DOM-Nodes. Kein unnötiger Recalculation-Overhead, spürbar schnellere Interaktionen.
Dazu kommt Vite 6 als Build-Tool mit nativem TypeScript-Support, Tree-Shaking und Code-Splitting auf Route-Ebene. Das Frontend wird als statische SPA über Cloudflare Pages ausgeliefert - global gecacht, automatisches HTTPS, optimale Auslieferung.
Backend: Cloudflare Workers + Hono
Das Backend läuft vollständig auf Cloudflare Workers. Statt eines klassischen Servers oder Containers nutzen wir V8 Isolates - leichtgewichtige Ausführungsumgebungen, die in Millisekunden starten und an über 300 Standorten weltweit verfügbar sind.
Als Web-Framework setzen wir Hono ein. Mit 13KB Gesamtgröße und einer Express-ähnlichen API ist Hono speziell für Edge-Runtimes gebaut. Zero Dependencies, TypeScript-first, und performant genug für unseren Anwendungsfall.
Der Worker ist dabei mehr als ein simpler Proxy. Er übernimmt eine zentrale Rolle in der Architektur: Er kommuniziert mit Shopifys GraphQL APIs, verarbeitet die Daten und serialisiert sie in ein kompaktes Format, bevor sie an den Client gehen.
Daten-Serialisierung: Kompakte Payloads statt GraphQL-Overhead
Ein typisches GraphQL-Response von Shopify enthält verschachtelte Objekte mit ausführlichen Feldnamen - gut lesbar, aber unnötig groß für die Übertragung über Satellit.
Unser Worker transformiert diese Responses in kompakte Array-Tupel. Statt eines Produkt-Objekts mit benannten Feldern schicken wir ein Array mit fester Positionslogik. Das Frontend weiß, an welcher Position welcher Wert steht. Das reduziert die Payload pro Produkt erheblich - bei einem Katalog mit hunderten Produkten summiert sich das.
Zusätzlich filtert der Worker serverseitig: Exklusive Produkte werden vor der Auslieferung entfernt, Metafields werden auf die relevanten Werte reduziert, Varianten werden in ein flaches Format gebracht. Der Client bekommt genau die Daten, die er für die Darstellung braucht - nicht mehr.
Bild-Optimierung: AVIF auf dem Edge
Produktbilder sind typischerweise der größte Bandbreiten-Faktor in einem E-Commerce-Shop. Unser Ansatz: Die Bilder werden nicht vom Client bei Shopifys CDN angefragt, sondern vom Worker als Proxy ausgeliefert.
Der Worker fordert das Originalbild bei Shopify an, konvertiert es über Cloudflare Image Resizing in AVIF, skaliert es auf die benötigte Größe (600px für Produktbilder, 520px Höhe für Hero-Banner) und setzt aggressive Quality-Parameter. Das Ergebnis wird über Cloudflares Cache mit 24-Stunden-TTL vorgehalten.
Der Client bekommt ein fertig optimiertes Bild in einem einzigen Request - ohne eigene Format-Verhandlung, ohne unnötige Größe, ohne mehrere Roundtrips.
Shopify-Integration: Storefront API + Admin API
Die Anbindung an Shopify erfolgt über zwei APIs:
Die Storefront API (GraphQL) liefert den Produktkatalog, Collections, Menü-Strukturen, Metaobjects für CMS-Inhalte und Shop Policies. Alles, was der Kunde sieht, kommt über diese API.
Die Admin API (GraphQL) wird für die Bestellabwicklung genutzt. Wenn ein Kunde den Checkout abschließt, erstellt der Worker einen Draft Order über die Admin API. Je nach Zahlungsmethode wird entweder eine Invoice per E-Mail verschickt (Pay after Flight) oder der Draft Order direkt in eine Bestellung überführt (Banküberweisung).
Für beide APIs nutzen wir Zeus als GraphQL-Client-Generator. Zeus generiert aus den Shopify-Schemas vollständig typisierte TypeScript-Clients. Jede Query ist zur Compile-Zeit validiert, Tippfehler in Feldnamen fallen sofort auf, und IDE-Autocomplete funktioniert lückenlos. Das reduziert Fehler und beschleunigt die Entwicklung erheblich.
Lokale Persistenz: IndexedDB als Offline-Puffer
Der Warenkorb und Produktdaten werden lokal in IndexedDB gespeichert. Das hat zwei Vorteile:
Erstens überlebt der Warenkorb Verbindungsabbrüche. Wenn die Satellitenverbindung kurz wegbricht - und das passiert - gehen keine Daten verloren. Der Kunde kann weiter browsen, Produkte hinzufügen und entfernen. Sobald die Verbindung steht, wird der Checkout möglich.
Zweitens reduziert die lokale Datenhaltung die Anzahl der API-Requests. Bereits geladene Produktdaten müssen nicht erneut vom Server abgerufen werden. Die Homepage-Inhalte nutzen zusätzlich einen Stale-While-Revalidate-Cache über localStorage - der Kunde sieht sofort Inhalte, während im Hintergrund geprüft wird, ob es Updates gibt.
Traffic-Analytics: Durable Objects mit ASN-Tracking
Für das Monitoring des Onboard-Shops setzen wir Cloudflare Durable Objects ein. Ein globales Durable Object aggregiert Traffic-Daten in Echtzeit: Request-Counts, Upload- und Download-Volumen, geschätzte Gzip-Größen - aufgeschlüsselt nach Stunden und nach Autonomous System Number (ASN).
Das ASN-Tracking ist besonders relevant: Wir können unterscheiden, ob ein Request über Satellit (also tatsächlich aus dem Flugzeug) oder über einen regulären ISP kommt. Das gibt uns und Condor ein klares Bild darüber, wie der Shop tatsächlich an Bord genutzt wird - ohne personenbezogene Daten zu erheben.
Die Daten werden in stündlichen Buckets gespeichert, automatisch zu Tages-Aggregaten zusammengefasst und nach 12 Monaten bereinigt. Ein integriertes Dashboard macht die Daten direkt zugänglich, inklusive Filterung nach ASN und Zeitraum.
Der Checkout: Pay after Flight
Das Herzstück des Onboard-Erlebnisses ist der Pay-after-Flight-Flow. Der Ablauf:
- Der Gast browst während des Fluges durch den Shop und legt Produkte in den Warenkorb.
- Im Checkout gibt er seine Daten ein - Versandadresse, optional abweichende Rechnungsadresse.
- Als Zahlungsmethode wählt er „Pay after Flight".
- Der Worker erstellt über die Shopify Admin API einen Draft Order und verschickt eine Invoice per E-Mail.
- Nach der Landung öffnet der Gast die E-Mail und bezahlt in Ruhe.
Architektur-Übersicht
Der Datenfluss ist bewusst einfach gehalten:
Die Solid.js SPA wird als statisches Bundle über Cloudflare Pages ausgeliefert. Alle API-Requests gehen an den Cloudflare Worker, der als einziger Kontaktpunkt zu Shopifys APIs fungiert. Der Worker kommuniziert mit der Storefront API für Katalogdaten und mit der Admin API für Bestellungen. Traffic-Daten fließen in ein Durable Object für Echtzeit-Analytics.
Der Client spricht zu keinem Zeitpunkt direkt mit Shopify. Alles läuft über den Worker - das gibt uns volle Kontrolle über Caching, Datenformat und Fehlerbehandlung.
Performance-Kennzahlen
| Metrik | Wert |
|---|---|
| Frontend-Framework | Solid.js (~7KB gzipped) |
| Backend-Framework | Hono (~13KB) |
| Bildformat | AVIF, serverseitig konvertiert |
| Lokaler Storage | IndexedDB (Warenkorb + Produktdaten) |
| Deployment | Cloudflare Pages + Workers |
| GraphQL-Client | Zeus (auto-generiert, typisiert) |
| Analytics | Durable Objects mit ASN-Tracking |
| Sprache | TypeScript (strict mode) |
Fazit: Headless Shopify, wenn es wirklich drauf ankommt
Dieses Projekt zeigt, was mit Shopify als Headless-Backend möglich ist, wenn man sich von Themes löst. Die Kombination aus Solid.js für ein minimales, reaktives Frontend, Cloudflare Workers für Edge-Processing und Shopifys GraphQL APIs als Commerce-Engine ergibt eine Architektur, die auch unter den extremen Bedingungen einer Satellitenverbindung auf 40.000 Fuß funktioniert.
Für Condor Airlines bedeutet das: keine separate Shop-Infrastruktur für den Onboard-Betrieb, keine doppelte Produktpflege, volle Integration in das bestehende E-Commerce-Ökosystem - und ein neuer Touchpoint für Kunden, der vorher schlicht nicht existierte.
