mongoose vs mongodb (modules / extensions nodejs), quel meilleur? et pourquoi?

Je viens d'arriver sur Node.js et je vois qu'il existe de nombreuses bibliothèques à utiliser avec MongoDB, les plus populaires semblent être celles-ci: (mongoose et mongodb). Puis-je obtenir les avantages et les inconvénients de ces extensions? Existe-t-il de meilleures alternatives à ces deux?

Edit: Nous avons trouvé une nouvelle bibliothèque qui semble également intéressante pour les nœuds mongols et qui est "Mongolian DeadBeef est un pilote Mongo DB node.js impressionnant qui tente de se rapprocher de près du shell mongodb." (readme.md)

https://github.com/marcello3d/node-mongolian

C'est juste pour ajouter plus de ressources aux nouvelles personnes qui voient cela, donc fondamentalement le mongol c'est comme un ODM ...

Mongoose est de niveau supérieur et utilise le pilote MongoDB (c'est une dépendance, vérifiez le package.json), donc vous l'utiliserez de toute façon compte tenu de ces options. La question que vous devriez vous poser est: "Est-ce que je veux utiliser le pilote brut ou ai-je besoin d'un outil de modélisation objet-document?" Si vous recherchez un outil de modélisation d'objets (ODM, un équivalent des ORM du monde SQL) pour ignorer certains travaux de niveau inférieur, vous voulez Mongoose.

Si vous voulez un pilote, parce que vous avez l'intention d'enfreindre de nombreuses règles qu'un ODM pourrait appliquer, optez pour MongoDB. Si vous voulez un pilote rapide et que vous pouvez vivre avec certaines fonctionnalités manquantes, essayez Mongolian DeadBeef: https://github.com/marcello3d/node-mongolian

La mangouste est, de loin, la plus populaire. Je l'utilise et n'en ai pas utilisé d'autres. Donc je ne peux pas parler des autres, mais je peux vous dire mes reproches avec Mongoose.

• Documentation difficile / médiocre
• Des modèles sont utilisés. Et ils définissent la structure de vos documents. Pourtant, cela semble étrange pour Mongo où l'un de ses avantages est que vous pouvez ajouter une colonne (err, attribut?) Ou simplement ne pas en ajouter.
• Les modèles sont sensibles à la casse - Moi-même et d'autres développeurs avec lesquels je travaille ont eu des problèmes où la casse du nom de la collection avec laquelle le modèle est défini peut l'empêcher de rien enregistrer, sans erreur. Nous avons constaté que l'utilisation de tous les noms en minuscules fonctionnait mieux. Par exemple, au lieu de faire quelque chose comme mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })il vaut mieux faire (même si le nom de la collection est vraiment MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Mais honnêtement, c'est vraiment utile. Le plus gros problème est la documentation. C'est là, mais c'est sec et difficile de trouver ce dont vous avez besoin. Il pourrait utiliser de meilleures explications et plus d'exemples. Mais une fois que vous avez passé ces choses, cela fonctionne vraiment très bien.

Je construis une nouvelle application et je conçois maintenant sa structure, voici quelques réflexions sur les raisons d'utiliser ou de ne pas utiliser la mangouste:

1. La mangouste sera plus lente (pour les grosses applications)
2. La mangouste est plus difficile avec des requêtes plus compliquées
3. Il y aura des situations où vous voudrez plus de vitesse et vous choisirez de vous passer de mangouste, alors vous aurez la moitié des requêtes avec la mangouste et la moitié sans mangouste. C'est une situation folle, une fois ...
4. Mongoose vous fera coder plus rapidement avec des applications simples avec une structure de base de données simple
5. Mongoose vous fera lire des documents mongodb ET des documents mangouste
6. Avec mangouste, votre pile aura une autre chose sur laquelle compter et c'est une possibilité de plus de s'écraser et de se réduire en cendres.

Le pilote mongodb est un pilote brut, vous communiquez directement avec mongodb. la mangouste est une couche d'abstraction. Vous obtenez des E / S plus faciles vers db tandis que votre structure de db est assez simple.

L'abstraction apporte ses exigences et vous devez les suivre. Votre application sera plus lente, consommera plus de RAM et sera plus compliquée, mais si vous savez comment l'utiliser, vous pouvez écrire plus rapidement des objets simples, les enregistrer dans la base de données.

Sans mangouste, vous aurez une application plus rapide avec une connexion directe à mongodb. Personne ne dit que vous ne pouvez pas écrire vos propres modèles pour enregistrer des éléments dans db. Vous pouvez. Et je pense que c'est plus facile. Vous écrivez du code, que vous utiliserez, vous savez ce dont vous avez besoin. Votre couche d'abstraction sera bien plus petite que celle de la mangouste.

Je viens du monde PHP, là nous avons eu sql brut avec des fonctions mysql_ dépréciées, puis nous avons obtenu PDO - couche d'abstraction orientée objet pour communiquer avec sql. Ou vous pouvez choisir un ORM lourd comme Doctrine pour avoir des choses similaires à la mangouste sur mongoDB. Objets avec la méthode setter / getters / save et ainsi de suite. C'est bien, mais en ajoutant plus d'abstraction, vous ajoutez plus de fichiers, plus de logique, plus de documentation, plus de dépendances. J'aime garder les choses simples et avoir moins de dépendances dans ma pile. BTW, c'est pourquoi je suis passé de PHP à Javascript serveur-client en premier lieu.

Avec mongoose, je pense que c'est génial d'écrire des applications simples, qui ont une structure de base de données simple similaire à SQL . Lorsque vous commencez à avoir des sous-documents et que vous voulez faire toutes ces requêtes folles, j'ai trouvé cela très difficile avec la mangouste. Vous devez consulter les documents de mongodb, puis consulter les documents de mangouste pour savoir comment faire une requête que vous voulez. Parfois, vous constaterez que X future de mongodb n'est pas en mangouste, alors vous passez au pilote brut de mongodb et écrivez des requêtes brutes de mongodb à un endroit ou à un autre. Sans mangouste, vous regardez les documents de mongodb et faites votre requête.

Je n'ai utilisé que mongodb. À mon avis personnel, je recommanderais de commencer par quelque chose de bas niveau, puis de monter. Sinon, vous risquez de vous retrouver à utiliser les fonctionnalités avancées supplémentaires fournies par des pilotes de niveau supérieur comme la mangouste sans aucun avantage réel.

Le problème que j'ai eu avec mongodb, qui est endémique à node.js, est la mauvaise documentation. Il y a de la documentation et beaucoup mais ce n'est pas toujours la plus utile. Ce que j'ai vu jusqu'à présent, il n'y a pas d'exemples bons et complets d'utilisation en production du pilote. La documentation contient le même exemple type d'ouverture d'une connexion, d'émettre une commande et de fermer la connexion. Vous pouvez dire qu'il est copié et collé à partir d'un modèle, car chaque exemple inclut requis pour tout ce qui pourrait être nécessaire plutôt que seulement ce qui est nécessaire pour chaque exemple.

Pour donner un exemple pris entièrement au hasard:

• raw {Boolean, default: false}, effectue des opérations en utilisant des tampons bson bruts.

Que fait exactement «effectuer des opérations à l'aide de tampons bson bruts»? Je ne trouve pas d'explication nulle part et une recherche Google pour cette phrase n'aide pas. Peut-être que je pourrais Google plus loin, mais je ne devrais pas avoir à le faire. Les informations devraient être là. Y a-t-il des avantages en termes de performances, de stabilité, d'intégrité, de compatibilité, de portabilité ou de fonctionnalité pour activer / désactiver cette option? Je n'ai vraiment aucune idée sans plonger profondément dans le code et si vous êtes dans mon bateau, c'est un problème sérieux. J'ai un démon où la persistance parfaite n'est pas requise mais le programme doit être très stable à l'exécution. Je pourrais supposer que cela signifie qu'il s'attend à ce que je désérialise et sérialise en JSON ou que c'est quelque chose de bas niveau, interne et transparent pour l'utilisateur, mais je peux me tromper. Bien que j'aie tendance à faire de bonnes hypothèses, je ne peux pas me fier à des hypothèses et à des conjectures lors de la création de systèmes vitaux. Donc, ici, je peux tester mon assertion avec du code ou creuser beaucoup plus profondément dans Google ou leur code. En tant que tel, ce n'est pas si mal, mais je me retrouve souvent dans cette situation en lisant leur documentation. La différence peut signifier les jours passés sur une tâche par rapport aux heures. J'ai besoin de confirmation et la documentation me donne à peine une explication, encore moins une confirmation.

La documentation est précipitée. Il n'explique pas les événements, donne des détails vagues sur le moment où des erreurs sont générées ou la nature de ces erreurs et il existe souvent plusieurs façons de réaliser la connectivité qui peuvent être peu claires. Vous pouvez vous en tirer et ce n'est pas complètement inutile, mais c'est très rugueux sur les bords. Vous constaterez que certaines choses sont laissées à des conjectures et à des expérimentations.