3.3MongoDB & Mongoose (base NoSQL)
Une application réelle a besoin de persister des données (les sauvegarder durablement) : utilisateurs, produits, commandes, messages… C'est le rôle d'une base de données. Dans l'écosystème Node, deux grandes familles s'offrent à vous : les bases NoSQL (dont MongoDB, cette section) et les bases SQL/relationnelles (section 3-4). MongoDB est une base de données NoSQL orientée documents très populaire avec Node. Au lieu de tables et de lignes (comme en SQL), MongoDB stocke des documents — des structures ressemblant à des objets JSON (en réalité BSON, du JSON binaire) — regroupés en collections. Un document utilisateur ressemble à { nom: "Alice", age: 30, roles: ["admin"] } — flexible, sans schéma rigide imposé par la base. Cette proximité avec les objets JavaScript/JSON explique en partie la popularité de MongoDB avec Node : les données ressemblent naturellement aux objets que vous manipulez en JS.
Pour travailler avec MongoDB en Node, on utilise très majoritairement Mongoose — un ODM (Object Document Mapper) qui ajoute une couche pratique par-dessus MongoDB. Mongoose apporte deux choses essentielles. Les schémas : bien que MongoDB soit « sans schéma », Mongoose vous permet (et vous encourage) à DÉFINIR la structure de vos documents — const userSchema = new mongoose.Schema({ nom: String, age: Number, email: { type: String, required: true, unique: true } }) — avec des types, des validations (requis, unique, contraintes), des valeurs par défaut. Cela apporte de la RIGUEUR (les données respectent une forme) tout en gardant la souplesse. Les modèles : à partir d'un schéma, Mongoose crée un modèle (const User = mongoose.model('User', userSchema)) qui offre des méthodes pour manipuler les documents. On réalise alors le CRUD (Create, Read, Update, Delete — les quatre opérations de base) : User.create({...}) ou new User({...}).save() (créer), User.find({...}) / User.findById(id) (lire), User.findByIdAndUpdate(...) (modifier), User.findByIdAndDelete(...) (supprimer). Ces méthodes sont ASYNCHRONES (elles renvoient des Promises — on utilise await), cohérent avec la nature de Node. Mongoose gère aussi les requêtes (filtres, tri, pagination, projection), les relations entre documents (références et « populate » pour joindre), les middlewares (hooks avant/après les opérations, utiles par exemple pour hacher un mot de passe avant l'enregistrement — section 4-2), et bien plus. Se connecter à MongoDB (mongoose.connect(url)) — que ce soit une base locale, ou un service cloud comme MongoDB Atlas (souvent utilisé) — puis modéliser ses données et faire un CRUD complet avec Mongoose est une compétence centrale du développement d'applications Node. Comprendre le modèle documentaire (documents/collections vs tables/lignes) et savoir utiliser Mongoose (schémas, modèles, CRUD asynchrone) vous permet de bâtir des applications qui persistent réellement leurs données — l'étape qui transforme un serveur « jouet » en application réelle.
Vocabulaire de la section
- Base de données / persistance
- Système sauvegardant durablement les données (utilisateurs, produits…). Deux familles : NoSQL (MongoDB) et SQL/relationnel (section 3-4).
- MongoDB (NoSQL orienté documents)
- Base stockant des DOCUMENTS (structures type JSON/BSON) regroupés en COLLECTIONS, sans schéma rigide ; proche des objets JS, populaire avec Node.
- Mongoose (ODM)
- Object Document Mapper ajoutant une couche pratique sur MongoDB : schémas (structure + validation), modèles (méthodes de manipulation).
- Schéma & modèle
- Le schéma définit la structure des documents (types, validations : required, unique, défauts) ; le modèle, créé depuis le schéma, offre les méthodes de manipulation.
- CRUD
- Les quatre opérations de base : Create (créer), Read (lire), Update (modifier), Delete (supprimer) ; en Mongoose, méthodes asynchrones (await).
MongoDB (NoSQL) : faut-il définir des schémas avec Mongoose ?
En pratique — Persister des données avec MongoDB et Mongoose
- Connectez-vous à MongoDB avec `mongoose.connect(url)` (base locale ou MongoDB Atlas en cloud).
- Définissez un schéma (types + validations : required, unique) et créez un modèle avec `mongoose.model('User', userSchema)`.
- Réalisez un CRUD complet (asynchrone, avec await) : create (créer), find/findById (lire), findByIdAndUpdate (modifier), findByIdAndDelete (supprimer).
- Explorez les requêtes (filtres, tri, pagination) et une relation entre documents (référence + populate).
Points clés à retenir
- Une application réelle PERSISTE ses données dans une base. Deux familles : NoSQL (MongoDB) et SQL/relationnel (3-4).
- MongoDB (NoSQL orienté DOCUMENTS) stocke des documents type JSON/BSON en COLLECTIONS (vs tables/lignes du SQL) — flexible, proche des objets JS.
- MONGOOSE (ODM) ajoute schémas (structure + VALIDATION : required, unique, types) et modèles (méthodes) : rigueur ET souplesse.
- CRUD asynchrone (await) : create / find(ById) / findByIdAndUpdate / findByIdAndDelete. Mongoose gère aussi requêtes, relations (populate), hooks (ex. hacher un mot de passe).
Questions fréquentes
MongoDB (NoSQL) ou SQL : comment choisir la base de données de mon projet ?
C'est une décision d'architecture importante, et le choix dépend de la NATURE de vos données et de vos besoins — les deux familles ont leurs forces, et ni l'une ni l'autre n'est universellement « meilleure ». Comprenons d'abord la différence fondamentale. Les bases SQL / relationnelles (PostgreSQL, MySQL…) organisent les données en TABLES (comme des feuilles de tableur) avec des LIGNES et des COLONNES, un SCHÉMA STRICT (structure définie à l'avance), et des RELATIONS formelles entre tables (clés étrangères). Elles utilisent le langage SQL pour les requêtes et garantissent des propriétés fortes (transactions ACID — cohérence, fiabilité). Les bases NoSQL orientées documents (MongoDB…) stockent des DOCUMENTS flexibles (type JSON), regroupés en COLLECTIONS, SANS schéma rigide imposé, avec une structure qui peut varier d'un document à l'autre. Quand MongoDB (NoSQL) convient bien : (1) Données flexibles / évolutives : quand la structure des données peut varier ou évoluer souvent (des documents avec des champs différents, des structures imbriquées) — la flexibilité de MongoDB est un atout. (2) Structures proches des objets/JSON : quand vos données ressemblent naturellement à des objets imbriqués (un document avec des sous-objets, des tableaux) — MongoDB les stocke tels quels, sans « éclatement » en plusieurs tables. Proximité naturelle avec JavaScript/JSON. (3) Prototypage rapide : sans schéma rigide à définir d'emblée, on démarre vite (mais attention, un schéma via Mongoose reste recommandé pour la rigueur). (4) Certains besoins de SCALE horizontal : MongoDB se distribue bien pour de très gros volumes (sharding). (5) Données peu relationnelles : quand les données n'ont pas beaucoup de relations complexes entre elles. Quand SQL (relationnel) convient mieux : (1) Données fortement RELATIONNELLES : quand vos données ont de nombreuses relations complexes (des utilisateurs liés à des commandes liées à des produits liés à des catégories…) — le relationnel excelle à modéliser et interroger ces relations (jointures). (2) Intégrité et cohérence critiques : applications financières, transactions, où la cohérence des données est vitale — les propriétés ACID et les transactions du SQL sont un gage de fiabilité. (3) Structure stable et bien définie : quand vos données ont une structure claire et stable, le schéma strict du SQL apporte rigueur et garanties. (4) Requêtes complexes : SQL est très puissant pour des requêtes analytiques complexes (agrégations, jointures multiples). (5) Standard éprouvé : le SQL est mature, universel, extrêmement maîtrisé. La réalité pratique : (1) Pour BEAUCOUP d'applications, les DEUX conviendraient — le choix se fait alors sur les préférences, l'écosystème, l'équipe. MongoDB est très populaire avec Node (proximité JSON, Mongoose agréable) et parfait pour apprendre et pour de nombreux projets. PostgreSQL est un choix relationnel excellent et très apprécié. (2) La distinction « NoSQL = flexible/scale, SQL = relationnel/cohérent » est une simplification — les deux ont évolué (MongoDB a des transactions, PostgreSQL gère du JSON…). (3) Le CHOIX dépend surtout de vos données : très relationnelles et cohérence critique → SQL ; flexibles/documentaires/proches des objets → MongoDB. En cas de doute, les deux sont de bons choix pour la plupart des applications web. Pour votre APPRENTISSAGE : (1) apprenez les DEUX familles (au moins les bases), car vous rencontrerez les deux dans votre carrière — ce guide couvre MongoDB (3-3) ET SQL (3-4). (2) MongoDB/Mongoose est un excellent point de départ avec Node (proximité JSON, expérience agréable), et couvre énormément de besoins. (3) Comprenez les CONCEPTS communs (persistance, CRUD, modélisation, requêtes) qui se transposent, au-delà de la techno spécifique. (4) Ne vous crispez pas sur « le meilleur » : ce sont des outils adaptés à des besoins, et savoir utiliser les deux vous rend polyvalent. En résumé : MongoDB (NoSQL documentaire) pour des données flexibles, proches des objets, peu ou moyennement relationnelles ; SQL (relationnel) pour des données fortement relationnelles, à cohérence critique, à structure stable. Beaucoup de projets pourraient utiliser l'un ou l'autre. Apprenez les deux (ce que fait ce guide), maîtrisez les concepts communs, et choisissez selon la nature de vos données et votre contexte. La compétence de PERSISTANCE (modéliser, faire du CRUD, requêter, gérer les relations) est centrale quelle que soit la base — c'est elle qui transforme un serveur en application réelle qui garde ses données.
Pourquoi utiliser Mongoose (un ODM) plutôt que MongoDB directement, et faut-il définir des schémas ?
Mongoose (l'ODM) ajoute une couche par-dessus MongoDB qui apporte structure, validation et confort — et OUI, définir des schémas est fortement recommandé même si MongoDB ne l'impose pas. Voyons pourquoi. Ce que Mongoose apporte par rapport à MongoDB « brut » : on POURRAIT utiliser le driver MongoDB directement (sans Mongoose), mais Mongoose ajoute des bénéfices précieux : (1) Les SCHÉMAS et la VALIDATION. C'est l'apport majeur. MongoDB est « sans schéma » — techniquement, vous pouvez y stocker n'importe quoi (des documents de structures totalement différentes dans la même collection). C'est flexible, mais DANGEREUX : sans discipline, vos données deviennent incohérentes (un document a un champ email, un autre e-mail, un troisième rien ; un âge est un nombre ici, une chaîne là). Le chaos de données garanti. Mongoose vous permet de DÉFINIR un schéma : la structure attendue (quels champs, quels types), avec des VALIDATIONS (champ requis, unique, contraintes de valeur, format). Ainsi, vos données respectent une forme cohérente, et les données invalides sont REJETÉES avant enregistrement (un email manquant, un âge négatif…). Vous gardez la flexibilité de MongoDB tout en imposant la rigueur nécessaire — le meilleur des deux mondes. (2) Les MODÈLES et les méthodes pratiques. Mongoose offre une API élégante et cohérente pour le CRUD (Model.create(), find(), findById(), findByIdAndUpdate()…), les requêtes (filtres, tri, pagination, chaînables), les relations (références + populate() pour joindre des documents liés) — plus confortable que le driver brut. (3) Les MIDDLEWARES/HOOKS : exécuter du code avant/après une opération (par exemple, hacher automatiquement un mot de passe AVANT chaque enregistrement — un pattern essentiel pour la sécurité, section 4-2 ; ou mettre à jour un champ « modifié le » automatiquement). (4) Les MÉTHODES et VIRTUELS personnalisés : ajouter des méthodes à vos modèles, des propriétés calculées. (5) La gestion des types et conversions : Mongoose gère les types, les conversions, les valeurs par défaut proprement. (6) Une expérience cohérente et documentée : Mongoose est le standard de facto pour MongoDB + Node, très utilisé, bien documenté. Faut-il DÉFINIR des schémas (puisque MongoDB ne l'impose pas) ? OUI, absolument, dans la quasi-totalité des cas, et voici pourquoi : (1) Cohérence des données : un schéma garantit que tous vos documents ont la même structure attendue — indispensable pour un code fiable (votre code s'attend à ce que chaque utilisateur ait un email ; sans schéma, rien ne le garantit). (2) Validation : le schéma REJETTE les données invalides (email manquant, type incorrect) AVANT qu'elles ne polluent votre base — une protection cruciale (les données invalides en base sont un cauchemar à nettoyer après coup). (3) Documentation vivante : le schéma DÉCRIT vos données (quels champs, quels types) — il sert de documentation claire de votre modèle de données, pour vous et votre équipe. (4) Sécurité : contrôler les champs (ne pas accepter n'importe quel champ envoyé par un client) protège contre certaines attaques (injection de champs non prévus). (5) Confiance dans le code : savoir que vos données respectent une forme définie rend votre code plus sûr et prévisible. L'argument « MongoDB est flexible, donc pas de schéma » est un piège de débutant : la flexibilité TECHNIQUE de MongoDB ne signifie pas qu'il FAILLE renoncer à la structure — au contraire, imposer un schéma (via Mongoose) vous donne la rigueur nécessaire tout en gardant la souplesse de MongoDB (vous pouvez faire évoluer le schéma, avoir des champs optionnels, des structures imbriquées). La flexibilité bien utilisée, c'est un schéma que VOUS contrôlez, pas l'absence de structure. En résumé : utilisez Mongoose (plutôt que MongoDB brut) pour ses schémas/validation, ses modèles pratiques, ses hooks et son confort. Et DÉFINISSEZ des schémas (même si MongoDB ne l'impose pas) pour la cohérence, la validation, la documentation et la sécurité de vos données — c'est une pratique essentielle qui distingue une application sérieuse d'un bricolage aux données chaotiques. La flexibilité de MongoDB est un atout quand on la maîtrise avec un schéma Mongoose ; un danger quand on l'utilise sans structure. Prenez le réflexe : toujours un schéma bien défini et validé pour vos données.