App Mobile 2022

Mealbox

Plateforme de commande de repas en entreprise sur Android et iOS, développée chez Prima IT Consulting.

Application Flutter destinée aux employés pour une plateforme de commande de repas en entreprise, adossée à une passerelle GraphQL que j'ai également construite sur NestJS et MongoDB.

#flutter#graphql#nestjs#mongodb#offline-cache#b2b

Mealbox est une plateforme de commande de repas en entreprise pour Android et iOS, développée durant mon passage chez Prima IT Consulting. Les employés se connectent via leur entreprise, parcourent le menu du jour par catégorie, ajoutent des plats au panier et gèrent leur profil.

J'ai travaillé des deux côtés de la passerelle GraphQL : le schéma et les resolvers sur un service NestJS adossé à MongoDB via Mongoose, et le client Flutter qui le consomme. Authentification par jeton, recherche d'entreprise par nom ou par localisation, et requêtes de menu servies par Hive selon une politique cache-puis-réseau.

Fonctionnalités clés

Connexion par entreprise

Authentification par jeton limitée à l'entreprise de l'employé : chaque utilisateur ne voit que les menus et les tarifs de sa propre organisation.

Menu par catégorie

Le menu du jour est structuré par catégorie, ce qui permet de composer un repas complet plutôt que de choisir des plats dans une liste à plat.

Recherche d'entreprise

Les employés trouvent leur organisation par nom ou par localisation de l'appareil, ce qui évite de distribuer des codes par entreprise.

Panier et profil

Composition de la commande et gestion du profil côté client, l'état de la commande restant local jusqu'à la validation.

Stack technique

FlutterDartProviderGraphQLNestJSMongoDBMongooseHive

Architecture

Le client s'adresse à une passerelle GraphQL unique plutôt qu'à un ensemble d'endpoints REST : l'application demande exactement les champs dont un écran a besoin au lieu de recevoir une charge fixe. La passerelle est un service NestJS ; la persistance repose sur MongoDB via Mongoose.

Les requêtes de menu suivent une politique cache-puis-réseau adossée à Hive : le menu en cache s'affiche immédiatement pendant que la requête réseau se résout en arrière-plan.

Défis & Solutions

Les problèmes complexes, et comment je les ai résolus.

Ouvrir sur un menu plutôt que sur un chargement

Les menus changent chaque jour mais l'application est ouverte à des heures prévisibles, souvent sur un réseau d'entreprise chargé. Charger à chaque lancement imposait une attente visible pour un contenu généralement vieux de quelques heures seulement. Servir d'abord depuis un cache Hive puis réconcilier avec le réseau rend la première image utile, au prix d'afficher brièvement un menu qui a pu changer.

Limiter chaque requête à la bonne entreprise

Un même déploiement sert plusieurs entreprises : une mauvaise portée expose les menus et les tarifs d'un client à un autre. La portée est imposée au niveau de la passerelle à partir du jeton plutôt que transmise par le client, qui ne peut donc pas demander de données hors de son organisation.

Plus de projets

Intéressé par une collaboration ?

Je suis toujours ouvert à discuter de nouveaux projets et opportunités.

Me contacter Voir tous les projets