Eine führende Marke für Sportartikel und -ausrüstung baute eine globale mobile Shopping-App auf und brauchte eine Backend-for-Frontend-(BFF)-Schicht, um Daten aus mehreren Diensten zu vereinheitlichen, personalisierte Produkt-Feeds auszuliefern und den Checkout schnell und zuverlässig zu halten, ohne die App demselben Instabilitätsrisiko wie das Web-Backend auszusetzen. Einen mobilen Release zu vermasseln ist teuer: App-Store-Freigabezyklen bedeuten, dass ein fehlerhaftes Update Tage oder Wochen kaputt bleiben kann, bevor ein Fix die Nutzer erreicht.
Tuix bettete über vier Jahre ein Team von bis zu sechs Entwicklern direkt in die Engineering-Organisation des Kunden ein: vier Senior-Full-Stack-Entwickler und zwei Mid-to-Senior-Entwickler, von denen einer zusätzlich als Software-Architekt bei zentralen technischen Entscheidungen mitwirkte. Ein Entwickler arbeitete in derselben Zeitzone wie das Kernteam des Kunden, nahm direkt an dessen Planungs und Architekturdiskussionen teil und gab Entscheidungen an den Rest des Embedded Teams weiter, so hatte der Kunde einen einzigen, konsistenten Ansprechpartner für die tägliche Abstimmung. Die übrigen fünf Entwickler arbeiteten aus Kolumbien und Argentinien, da der US-Markt für den Kunden Priorität hatte. Diese Flexibilität von Tuix verschaffte dem Kunden effektive Abdeckung über Regionen und Entscheidungen hinweg, ohne dass sich ein einzelner Ingenieur über jede Stunde des Tages strecken musste, und dabei trotzdem die volle Schlagkraft eines sechsköpfigen Teams.
Das Engagement begann mit einem zweiköpfigen eingebetteten Team. Von da an endete die Zusammenarbeit nicht mit dem Launch: Als die Engineering-Organisation des Kunden weitere angrenzende Bedarfe erkannte, die es zu lösen galt, baute Tuix das Team schrittweise auf sechs Entwickler aus und ließ die Teamgröße mit dem Umfang der Arbeit mitwachsen. Während ein Teil des Teams die BFF weiter baute und betreute, übernahmen andere eine Anwendung zur Sendungs- und Warenverfolgung per RFID, Lagerverwaltungssysteme zur Anlage und Pflege von Produktdatensätzen sowie die Synchronisierung von Materialien und Informationen von Lieferanten. Statt eines Projekts, das am Ende eines Vertrags übergeben wird, war es ein Team, das wuchs und so lange eingebettet blieb, wie der Kunde gemeinsam mit Tuix neue Bedarfe zu lösen fand.
Während die mobile App selbst separat von den eigenen Entwicklern des Kunden in Flutter gebaut wurde, arbeitete das Tuix-Team in enger, fortlaufender Zusammenarbeit mit ihnen: gemeinsame Lösung von Integrationsherausforderungen, Feinabstimmung der API-Antworten an die tatsächlichen Bedürfnisse des Frontends und Aufrechterhaltung der Backend-Kompatibilität, während sich das Frontend weiterentwickelte. Diese enge Abstimmung zwischen den beiden Teams war ebenso Teil des Engagements wie die Backend-Arbeit selbst.
Backend-for-Frontend-(BFF)-Kern Im Zentrum der Lösung stand ein NestJS-GraphQL-BFF als einheitliches Gateway für die mobile App. Es aggregierte Daten aus mehreren Backend-Diensten, wandte Geschäftslogik an und lieferte nur die benötigten Informationen zurück – das reduzierte die Payload-Größe und optimierte die Performance für mobile Nutzer.
Geschwindigkeit durch Caching Eine Redis-Caching-Schicht beschleunigte häufige Abfragen, verkürzte Antwortzeiten und reduzierte die Last auf den Backend-Diensten.
Intelligente Sucherfahrung Algolia lieferte sofortige, relevante Suchergebnisse und sorgte für einen reibungslosen, reaktionsschnellen Produktentdeckungsprozess. Proaktives Monitoring Wir integrierten New Relic und Amplitude für tiefgehendes Performance- und Nutzungsmonitoring, was schnelle Erkennung und Behebung potenzieller Probleme ermöglichte, bevor sie Endnutzer betrafen.
Enge Zusammenarbeit mit den Frontend-Teams Während das mobile Frontend separat in Flutter entwickelt wurde, arbeiteten wir eng mit den Entwicklern des Kunden zusammen, um Integrationsherausforderungen zu lösen, API-Antworten fein abzustimmen und die Backend-Kompatibilität mit den sich entwickelnden Frontend-Anforderungen sicherzustellen.
Backend
NestJS (TypeScript) GraphQL-API (BFF-Schicht) Redis Hochgeschwindigkeits-Caching-Schicht Kubernetes Container-Orchestrierung für skalierbare Deployments AWS Hosting-, Storage- und Infrastrukturdienste
Integrationen
Algolia Sofortige, relevante Suchfunktionalität Amplitude & New Relic Echtzeit-Monitoring und Performance-Tracking Firebase Benachrichtigungen und Echtzeit-Updates E-Commerce-Dienste Produkt-, Bestell- und Nutzerverwaltung, aufbauend auf dem bestehenden Web-Anwendungs-Backend, durch das BFF optimiert für Performance und angepasste Antworten für die mobile Erfahrung.
NestJS' GraphQL-API verschaffte der mobilen App maßgeschneiderte, flexible Datenauslieferung und ließ sie genau die Felder abrufen, die sie pro Ansicht brauchte, statt zu viel zu laden, während das BFF-Muster mobile Anforderungen sauber von der Backend-Komplexität trennte und künftige Updates erleichterte. Redis-Caching senkte Antwortzeiten und Backend-Last für häufig abgerufene und weitgehend statische Daten, Algolia lieferte typo-tolerante Suche mit Facettenfilterung in unter einer Sekunde, und New Relic zusammen mit Amplitude gab volle Transparenz über Systemgesundheit und Nutzerverhalten, sodass Probleme früh erkannt und die Erfahrung fortlaufend verbessert werden konnten. AWS und Kubernetes rundeten eine hochverfügbare, selbstheilende Infrastruktur ab, gebaut zur Skalierung. Weil das Embedded Team vier Jahre blieb, statt nach dem Launch zu übergeben, wurden diese Entscheidungen mit dieser vollen Lebensdauer im Blick getroffen, zugunsten eines Stacks, den das Team selbst Jahre später noch pflegen und erweitern würde.
Echtzeit-Performance-Tracking über New Relic; alle Monitoring und Logging-Pipelines wurden mit Datenobfuskation konzipiert, damit niemals sensible Kundendaten oder personenbezogene Informationen offengelegt wurden; Nutzungs und Traffic-Einblicke segmentiert nach Zeitzone, Gerät und Region; Incident-Alerts über Slack; Incident-Playbooks und Post-Mortems; stündliche automatisierte End-to-End-Tests; CI/CD-Qualitäts-Gates (Unit-, Integrations-, E2E-Tests, SonarCloud); ein GraphQL-Schema-Checker, um Breaking Changes zu erkennen, bevor sie den langsameren Freigabezyklus des App Stores erreichten. Diese Disziplin vier Jahre lang durchzuhalten, war nur realistisch, weil dasselbe Embedded Team sie die ganze Zeit über durchsetzte, statt dass Praktiken bei jedem Vendor-Wechsel wieder verblassten.
Absicherung gegen Frontend-Risiken: Die Veröffentlichung von Updates im iOS App Store und im Google Play Store durchläuft einen langen Freigabeprozess. Ein zentraler Grund für die Einführung einer BFF-Schicht, statt dasselbe Backend wie die Retail-Website freizulegen, war deshalb, mobil-spezifische Abhängigkeiten von instabilem oder experimentellem Website-Frontend-Code zu vermeiden. Jeder durchgerutschte Frontend-Fehler hätte echte Ausfallzeiten oder Frustration bei den Nutzern verursachen können, verschärft dadurch, wie langsam App-Store-Fixes ausgerollt werden können. Das BFF fungierte als Sicherheitspuffer, der der App nur stabile, mobil-optimierte Daten lieferte.
Reibungslose Abwärtskompatibilität: Anders als bei Web-Apps können mobile Nutzer wochen oder monatelang auf älteren App-Versionen bleiben, sodass ein Update-Zwang bei jedem Sprint unnötige Reibung verursacht hätte. Das BFF passte Dienste im laufenden Betrieb an, um mit älteren Versionen abwärtskompatibel zu bleiben, und hielt die Erfahrung reibungslos, ohne störende Zwangs-Updates.
Optimierte mobile Datenauslieferung Backend auf mobile Geräte zugeschnitten, um Payloads zu minimieren und die Geschwindigkeit zu steigern.
Hochgeschwindigkeitssuche Algolia-Integration für sofortige Produktentdeckung.
Performance-getriebene Architektur Redis-Caching und Kubernetes-Orchestrierung für Stabilität und Skalierbarkeit.
Nahtlose E-Commerce-Integration Anbindung an bestehende Produkt-, Bestands- und Bestellsysteme.
Zusammenarbeit von Backend und Frontend Fortlaufender Support und Fehlerbehebung für eine reibungslose Integration mit der Flutter-App.
Der schwierigste Teil dieses Engagements war nicht der Code, sondern die enge Synchronisation mit einem externen Flutter-Team, das wir nicht selbst führten, bei einem knappen initialen Lieferzeitfenster, während gleichzeitig etwas gebaut wurde, das weit über den Launch hinaus Bestand haben sollte. Das erforderte ständige Kommunikation und schnelle Iteration, um beide Seiten synchron zu halten, strikte Priorisierung, um den Termin zu halten, ohne bei den Grundlagen Abstriche zu machen, und Architekturentscheidungen, die mit vier Jahren zukünftiger Features im Blick getroffen wurden, nicht nur mit dem ersten Release. Die frühe Einführung von New Relic zahlte sich genauso aus wie der Rest des Embeds: Probleme wurden erkannt, bevor sie die Nutzer erreichten, statt danach.
