L'expansion de FuelBuddy aux Émirats arabes unis nécessitait une application de franchise dédiée, adaptée aux exigences opérationnelles régionales. J'ai construit l'application de franchise Dubaï de zéro, à la fois sur le frontend et sur les API de données.
Ce que j'ai construit
- Frontend greenfield : Construction du système de composants et de la structure applicative depuis zéro, livrant une interface propre et responsive pour les opérations de franchise.
- API Hasura GraphQL : Construction de la couche de données backend sur le moteur Hasura GraphQL, en définissant les opérations CRUD et les modèles de données nécessaires à l'application.
- Cartes, planification et exports : Intégration de cartes en direct, d'une vue de planification calendrier/Gantt, et d'export tableur/PDF pour le reporting des franchises.
- Authentification et sécurité : Configuration d'une authentification adossée à Firebase avec un contrôle d'accès par rôle appliqué via les propres claims JWT de Hasura.
Pourquoi c'était important
Livrer une plateforme dédiée a donné aux opérateurs de franchise de FuelBuddy aux Émirats arabes unis un outil conçu sur mesure pour les opérations régionales, sur une stack pensée pour des données cartographiques en temps réel et un reporting lourd.
La couche de données
Cette application récupère ses données via graphql-request contre un SDK typé généré par codegen, avec des stores Pinia portant l'état client, sans aucune trace de TanStack Query dans l'arbre de dépendances. L'authentification repose sur Firebase, et le contrôle d'accès par rôle provient des propres claims JWT personnalisées de Hasura (x-hasura-default-role, x-hasura-user-id) plutôt que d'un système de permissions construit séparément.
Plus qu'un simple générateur de formulaires
C'est une application réellement riche en fonctionnalités pour ce qui aurait pu être un simple outil CRUD : Mapbox GL associé à mapbox-gl-draw pour dessiner et modifier les zones de franchise directement sur la carte, FullCalendar associé à vue-ganttastic pour la planification façon Gantt, Chart.js pour les tableaux de bord de reporting, et un pipeline d'export complet (xlsx, papaparse, jszip, html2pdf.js, dom-to-image, html-to-image) pour que les rapports de franchise sortent de l'application sous forme de tableurs, de PDF ou d'images selon le besoin de l'opérateur, pas un format unique et figé.
Généré, pas écrit à la main
Les opérations GraphQL sont générées au moment du build via vite-plugin-graphql-codegen contre codegen.yml, produisant un client src/sdk.ts typé à partir du schéma Hasura. Chaque requête et mutation est typée contre le schéma en direct au lieu de chaînes écrites à la main qui dérivent silencieusement quand le backend change.
Ce que couvrent les tests
Playwright couvre deux flux de bout en bout : la connexion et la gestion des commandes, la porte d'entrée derrière laquelle se trouve chaque autre écran et la transaction centrale que l'application existe pour gérer. Tout ce qui vient après ces deux flux (planification, exports, reporting) est une surface plus récente que les tests, pas un oubli.
Stack
Vue 3, Vite, Pinia, graphql-request avec GraphQL Code Generator contre Hasura, Firebase pour l'authentification, Mapbox GL avec mapbox-gl-draw, FullCalendar avec vue-ganttastic, Chart.js pour le reporting, Playwright pour les tests.