Build the v1 of the API

Avec zéro connaissance en back-end, j’ai construit une API complète pour un projet perso. Parti de rien, j’ai choisi Express et Sequelize avec PostgreSQL pour leur simplicité, leur contrôle précis et leur indépendance totale.

Le déclic : besoin d’une vraie base de données

Dressmi avait besoin de stocker et gérer des données structurées – des ressources liées entre elles, avec des relations complexes et une granularité fine. PostgreSQL s’imposait pour ses requêtes SQL puissantes, ses transactions ACID et sa capacité à gérer des jointures précises sans compromettre les performances.
Je ne connaissais pas Supabase à l’époque, et même si c’est génial pour du rapide, je voulais quelque chose d’indépendant : mon propre serveur, mes propres règles, sans dépendre d’un service tiers qui pourrait limiter mes évolutions futures. Firebase, par exemple, est ultra-simple pour du NoSQL schemaless et realtime (auth intégrée, Firestore scalable), mais parfait pour des apps mobiles ou prototypes sans structure rigide – or mon cas réclamait des relations SQL strictes et des queries custom que Firebase rend plus compliquées sans extensions.
PostgreSQL offrait cette liberté totale, avec un niveau de détail que des bases NoSQL n’auraient pas permis pour mon use case.

Pourquoi Express et Sequelize : le duo parfait pour débutants

Express est le choix n°1 pour un premier back-end en Node.js : minimaliste, flexible, avec un écosystème immense de middlewares et tutos accessibles qui te permettent de router des endpoints en minutes sans boilerplate inutile. Contrairement à Firebase Functions (serverless mais limitées en durée/custom), Express te donne un vrai serveur persistant et full custom.
Sequelize, l’ORM promise-based, évite d’écrire du SQL brut au début tout en gérant migrations, modèles et relations – idéal pour un newbie qui veut se concentrer sur la logique métier plutôt que sur les queries, loin du paradigme document-oriented de Firebase.
Ce stack bat les alternatives pour un débutant : plus stable que des trucs comme NestJS, plus structuré que du raw Node, et parfait pour une API REST CRUD scalable sans courbe d’apprentissage abrupte.

La structure que j’ai adoptée

J’ai organisé mon projet en dossiers clairs pour ne pas me perdre : server.js pour le bootstrap Express, routes/ pour les endpoints groupés par ressource, models/ avec Sequelize pour les schémas et relations, et migrations/ pour versionner la BDD.
Exemple basique d’un model User : Sequelize me permettait de définir relations (User hasMany Posts) et validations en JS pur, sync avec PostgreSQL en un sequelize.sync(). Pour les routes, un simple router.get('/users', async (req, res) => { const users = await User.findAll(); res.json(users); }) – Express rend ça intuitif, et Sequelize gère l’async sans sueur.

Leçons, la réalité et la fin abrupte du projet

Malgré l’indépendance totale promise, construire une API from scratch reste hyper complexe. Sécurité : il faut gérer CORS, rate limiting, input sanitization, JWT auth robuste, HTTPS forcé, protection CSRF/XSS/SQL injection – des failles critiques que j’ai à peine effleurées à l’époque, risquant des breaches si l’app prenait de l’ampleur.
Côté financier, un VPS c’est 10-50€/mois mini + temps pour OS updates, backups, monitoring, scaling – sans compter la responsabilité légale si tu gères des millions de comptes avec tes propres skills limités en prod.
Aujourd’hui (spoiler : je l’ai refait récemment), je partirais direct sur Supabase ou Firebase : auth/sécurité gérée, scaling auto, coûts prévisibles, et focus sur mon métier (design/front) sans ops nightmare. Express+Sequelize reste top pour apprendre, mais pour du réel, les BaaS gagnent. Malheureusement, faute de temps, j’ai dû abandonner ce projet une fois l’API fonctionnelle – une leçon : prioriser MVP ultra-minimal pour valider avant d’investir. Si tu es designer/front comme moi et veux plonger en back, teste ce stack pour comprendre, mais passe vite à Supabase pour scaler sans stress.