Snurlax Cosmetics API
Le backend e-commerce d'une marque de cosmétiques, développé à deux. Une API Express et MongoDB couvrant comptes, produits, catégories, panier, favoris et commandes, avec authentification JWT et hachage bcrypt, un rôle administrateur et la vérification par téléphone, l'upload d'images via Multer, les emails transactionnels via Nodemailer et les notifications push via Firebase. Packagé avec Docker Compose pour le déploiement.
- Mon rôle
- Développeur Backend
- Période
- août 2023 – oct. 2023
- Statut
- Livré
Il s'agit de la partie serveur de la boutique en ligne d'une marque de cosmétiques, développée chez Snurlax Digital : une API REST qui accompagne l'acheteur du catalogue jusqu'à la commande, consommée par une application mobile Flutter développée en parallèle par un collègue. C'était mon premier poste professionnel, chez Snurlax Digital, en tant que moitié backend d'une équipe de deux développeurs — chaque endpoint faisait donc office de contrat pour le client mobile.
L'API s'organise autour des objets métier de la boutique — utilisateurs, produits, catégories, paniers, favoris et commandes — persistés en documents MongoDB derrière des routes Express. Les préoccupations transverses vivent dans des middlewares : vérification JWT sur les routes protégées, contrôle du rôle admin sur la gestion du catalogue, parsing Multer sur les endpoints d'upload d'images. Les messages sortants passent par Nodemailer pour l'e-mail transactionnel et par Firebase pour le push, et Docker Compose exécute l'API et la base comme une seule pile reproductible.
Le problème à résoudre
Un backend e-commerce doit réussir les parties ingrates : des comptes qu'on ne peut pas détourner, un parcours de commande qui reflète le contenu réel du panier, et une surface d'administration hors de portée des acheteurs. Ici, tout cela — identité, catalogue, achat, upload de médias et messagerie sortante — devait tenir dans un seul service, livré lors d'un premier poste professionnel, pendant qu'un collègue construisait le client Flutter contre la même API : les endpoints devaient rester assez stables et prévisibles pour servir de contrat entre deux personnes travaillant en parallèle.
Comment cela a été construit
Le service est une application Express unique, avec un module de routes par ressource et des collections MongoDB en dessous. L'inscription stocke des identifiants hachés avec bcrypt ; la connexion les échange contre un JWT qu'un middleware valide sur les routes protégées. Un rôle administrateur verrouille la gestion du catalogue, et la vérification téléphonique rattache chaque compte à un numéro joignable. Les images produits arrivent en upload multipart via Multer, l'e-mail transactionnel part via Nodemailer, et Firebase transporte les notifications push vers l'application mobile.
Docker Compose déclare l'API et sa base comme une seule pile : le backend contre lequel le développeur Flutter codait en local est le même que celui déployé, démarré en une commande plutôt que sur un serveur configuré à la main.
Ce que ça fait
Auth JWT et bcrypt
Les mots de passe sont stockés en hachés bcrypt et les sessions reposent sur des JWT ; un middleware contrôle le jeton sur chaque route protégée.
Vérification téléphonique
Chaque compte confirme un numéro de téléphone, second contrôle d'identité en plus de l'e-mail et du mot de passe.
Catalogue produits par catégories
Les endpoints produits et catégories alimentent la navigation ; l'écriture est réservée au rôle administrateur.
Panier, favoris, commandes
Tout le parcours d'achat est côté serveur : l'acheteur gère un panier et une liste de favoris, et le panier devient une commande.
Upload d'images via Multer
Les endpoints d'images acceptent des uploads multipart via Multer et fournissent au catalogue ses visuels produits.
E-mail et push
Nodemailer envoie l'e-mail transactionnel et Firebase livre les notifications push au client Flutter.
Construit avec
Backend
Express maintient l'API REST légère : chaque domaine — produits, panier, commandes — est un routeur, et la vérification JWT, le contrôle admin et le parsing Multer se composent en middlewares devant les handlers.
La charge est presque entièrement de l'I/O — lectures en base, uploads d'images, envoi d'e-mails et de push — que la boucle d'événements non bloquante de Node sert depuis un seul runtime JavaScript.
Données
Les entités du catalogue et les documents par utilisateur — panier, favoris — correspondent directement à des documents MongoDB, renvoyés au client Flutter sous les mêmes formes JSON.
Firebase Cloud Messaging prend en charge la livraison des push vers l'application Flutter sur les deux plateformes ; le backend se contente de déclencher les notifications au lieu de maintenir des connexions vers les téléphones.
Infrastructure
Docker Compose décrit l'API et MongoDB comme une seule pile : les deux développeurs et le serveur de déploiement exécutent un environnement identique en une commande.