Bei FuelBuddy war ich Kern-Engineer an der Franchise Application, mit der Franchise-Betreiber regionale Hubs, Bestand und Lieferflotten verwalten.
Was ich gebaut habe
- Live-LKW-Tracking: Ein interaktives Google-Maps-Modul gebaut, das die Standorte der Flotte in einem Polling-Intervall anzeigt und Betreibern durchgehende Sichtbarkeit auf LKW-Bewegungen und Dispositionsstatus gibt.
- GraphQL-APIs und Caching: Daten-APIs mit der Hasura-GraphQL-Engine über urql gebaut, mit einem normalisierten clientseitigen Cache und automatischer Token-Erneuerung bei Ablauf.
- Vereinfachung der Abläufe: Mehrstufige operative Aufgaben, darunter Bestandsabgleich und Fahrerzuweisung, in schlankere Oberflächen überarbeitet, die operative Fehler reduzierten.
Warum es wichtig war
Die Flottenverfolgung machte die Dispositionslogistik planbarer und reduzierte Standzeiten der LKWs. Schlankere Zuweisungs- und Bestandsabläufe reduzierten operative Fehler über die Franchise-Hubs hinweg.
Was „Live“ hier tatsächlich bedeutet
Die LKW-Karte aktualisiert sich in einem Polling-Intervall, nicht über ein GraphQL-Subscription, obwohl derselbe Client an anderer Stelle in der App für Subscriptions verdrahtet ist (graphql-ws ist konfiguriert und wird für Bestellstatus-Updates genutzt, nur nicht für diese Karte). Das war ein bewusster Kompromiss bei den Serverkosten, kein Versehen: Eine Subscription hält eine dauerhafte Verbindung auf dem Server offen, solange der Client sie geöffnet hat, und ein Kartenbildschirm, der über jede Disponenten-Schicht hinweg stundenlang geöffnet bleibt, ist eine weit schwerere, länger anhaltende Verbindungslast als ein einmaliges Bestellstatus-Update. Polling vermeidet es, diese Verbindung überhaupt offenzuhalten, und tauscht sie stattdessen gegen periodische Anfrage-/Antwort-Zyklen ein.
Zuweisung und Bestand im Detail
Die Fahrerzuweisung deckt Einzel-, Sammel-, Umzuweisungs- und Aufhebungs-Abläufe ab, nicht nur eine einzelne „Zuweisen“-Aktion. Die Bestandsverfolgung verfolgt Lagerbestände speziell für Fuel Bowser (Tankwagen), mit dedizierten Bestandsabfragen und Log-Tabellen, ein echtes operatives Datenmodell und kein generischer Teile-Bestand.
Datenmodell & Skalierung
- urqls normalisierter Cache plus eine Firebase-Token-Authentifizierungsschicht, die sich bei 401-/abgelaufene-Token-Antworten automatisch erneuert, sodass eine abgelaufene Sitzung einen Disponenten nicht mitten in einer Aufgabe unterbricht.
- Playwright deckt Login und Bestellverwaltung end to end ab, die zwei Abläufe, von denen jeder andere Bildschirm in der App abhängt.
Stack
Vue 3, Vite, Pinia, urql gegen Hasura, Firebase-Authentifizierung, Google Maps, Playwright für Tests.