mongoose vs mongodb (moduli / estensioni nodejs), quale migliore? e perché?

Sono appena arrivato su Node.js e vedo che ci sono molte librerie da usare con MongoDB, le più popolari sembrano essere queste due: (mongoose e mongodb). Posso ottenere vantaggi e svantaggi di queste estensioni? Esistono alternative migliori a questi due?

Modifica: trovata una nuova libreria che sembra interessante anche node-mongolian ed è "Mongolian DeadBeef è un fantastico driver Mongo DB node.js che tenta di approssimare da vicino la shell mongodb." (Readme.md)

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

Questo è solo per aggiungere più risorse a nuove persone che lo vedono, quindi fondamentalmente mongolo è come un ODM ...

Mongoose è di livello più alto e utilizza il driver MongoDB (è una dipendenza, controlla il package.json), quindi lo utilizzerai in entrambi i modi date queste opzioni. La domanda che dovresti porci è: "Voglio usare il driver raw o ho bisogno di uno strumento di modellazione di documenti oggetto?" Se stai cercando uno strumento di modellazione di oggetti (ODM, una controparte degli ORM del mondo SQL) per saltare un lavoro di livello inferiore, vuoi Mongoose.

Se vuoi un driver, perché intendi infrangere molte regole che un ODM potrebbe applicare, vai con MongoDB. Se vuoi un driver veloce e puoi convivere con alcune funzionalità mancanti, prova il mongolo DeadBeef: https://github.com/marcello3d/node-mongolian

La mangusta è, di gran lunga, la più popolare. Lo uso e non ne ho usati altri. Quindi non posso parlare degli altri, ma posso dirti le mie lamentele con Mongoose.

• Documentazione difficile / scarsa
• Vengono utilizzati modelli . E definiscono la struttura dei tuoi documenti. Eppure questo sembra strano per Mongo dove uno dei suoi vantaggi è che puoi inserire una colonna (err, attributo?) O semplicemente non aggiungerne una.
• I modelli fanno distinzione tra maiuscole e minuscole - Io e altri sviluppatori con cui lavoro abbiamo avuto problemi in cui il caso del nome della raccolta con cui è definito il modello può far sì che non salvi nulla, senza errori. Abbiamo scoperto che l'utilizzo di tutti i nomi minuscoli funziona meglio. Ad esempio, invece di fare qualcosa di simile mongooseInstace.model('MyCollection', { "_id": Number, "xyz": String })è meglio fare (anche se il nome della raccolta è davvero MyCollection):mongooseInstace.model('mycollection', { "_id": Number, "xyz": String })

Ma onestamente, è davvero utile. Il problema più grande è la documentazione. È lì, ma è asciutto e difficile da trovare ciò di cui hai bisogno. Potrebbe utilizzare spiegazioni migliori e più esempi. Ma una volta superate queste cose funziona davvero molto bene.

Sto costruendo una nuova app e ne sto progettando la struttura, ecco alcune riflessioni sul perché usare o meno la mangusta:

1. La mangusta sarà più lenta (per grandi app)
2. Mongoose è più difficile con query più complicate
3. Ci saranno situazioni in cui vorrai più velocità e sceglierai di andare senza mangusta, quindi avrai metà domande con mangusta e metà senza. È una situazione folle, una volta ...
4. Mongoose ti farà scrivere codice più velocemente con app semplici con una struttura db semplice
5. Mongoose ti farà leggere documenti mongodb E documenti mongoose
6. Con mongoose il tuo stack avrà un'altra cosa da cui dipendere ed è un'altra possibilità di schiantarsi e ridursi in cenere.

Il driver mongodb è un driver grezzo, comunichi direttamente con mongodb. la mangusta è uno strato di astrazione. Ottieni un I / O più facile per db mentre la struttura del tuo db è abbastanza semplice.

L'astrazione introduce i suoi requisiti e devi seguirli. La tua app sarà più lenta, consumerà più RAM e sarà più complicata, ma se sai come usarla, puoi scrivere più velocemente oggetti semplici, salvandoli nel database.

Senza mangusta avrai un'applicazione più veloce con connessione diretta a mongodb. Nessuno dice che non puoi scrivere i tuoi modelli per salvare cose su db. Puoi. E penso sia più facile. Scrivi codice, che userai, sai di cosa hai bisogno. Il tuo livello di astrazione sarà molto più piccolo, quindi quello della mangusta.

Vengo dal mondo PHP, lì avevamo sql grezzo con funzioni mysql_ deprezzate, quindi abbiamo ottenuto PDO - livello di astrazione orientato agli oggetti per comunicare con sql. Oppure puoi scegliere un ORM pesante come Doctrine per avere cose simili a mongoose su mongoDB. Oggetti con metodo setter / getters / save e così via. Va bene, ma aggiungendo più astrazione stai aggiungendo più file, più logica, più documentazione, più dipendenze. Mi piace mantenere le cose semplici e avere meno dipendenze nel mio stack. A proposito, è per questo che sono passato da PHP a Javascript server-client in primo luogo ..

Con mongoose penso che sia fantastico scrivere alcune semplici app, che hanno una struttura db semplice simile a sql . Quando inizi ad avere documenti secondari e vuoi fare tutte quelle domande folli, l'ho trovato davvero difficile con la mangusta. Devi guardare i documenti mongodb, quindi guardare i documenti mongoose per scoprire come eseguire una query che desideri. A volte scoprirai che il futuro X di mongodb non è in mongoose, quindi vai al driver mongodb grezzo e scrivi query mongodb non elaborate in uno o in un altro posto. Senza mangusta, guardi i documenti di mongodb e fai la tua domanda.

Ho usato solo mongodb. A mio parere personale, consiglierei di iniziare con qualcosa di basso livello e poi salire. Altrimenti potresti ritrovarti a utilizzare le funzionalità avanzate aggiuntive fornite da driver di livello superiore come la mangusta senza alcun vantaggio effettivo.

Il problema che ho avuto con mongodb, che è endemico per node.js, è la scarsa documentazione. C'è documentazione e molta, ma non è sempre la più utile. Quello che ho visto finora non ci sono buoni e completi esempi di utilizzo di produzione del driver. La documentazione è riempita con lo stesso esempio modellato di aprire una connessione, emettere un comando e chiudere la connessione. Puoi dire che è copiato e incollato da un modello perché ogni esempio include il necessario per tutto ciò che potrebbe essere necessario piuttosto che solo ciò che è necessario per ogni esempio.

Per fare un esempio preso del tutto a caso:

• raw {Boolean, default: false}, esegue le operazioni utilizzando i buffer bson non elaborati.

Che cosa fa esattamente "esegue operazioni utilizzando buffer bson non elaborati"? Non riesco a trovarlo spiegato da nessuna parte e una ricerca su Google per quella frase non aiuta. Forse potrei cercare ulteriormente su Google ma non dovrei farlo. Le informazioni dovrebbero essere lì. Ci sono prestazioni, stabilità, integrità, compatibilità, portabilità o vantaggi funzionali per abilitare / disabilitare questa opzione? Non ne ho idea senza immergermi profondamente nel codice e se sei nella mia barca è un problema serio. Ho un demone in cui non è richiesta una persistenza perfetta, ma il programma deve essere molto stabile in fase di esecuzione. Potrei presumere che questo significhi che si aspetta che deserializzi e serializzi in JSON o sia qualcosa di di basso livello, interno e trasparente per l'utente, ma potrei sbagliarmi. Anche se tendo a fare buone supposizioni, non posso fare affidamento su supposizioni e supposizioni quando creo sistemi vitali. Quindi qui posso testare la mia affermazione con il codice o scavare molto più a fondo in Google o nel loro codice. Come una tantum non è così male, ma mi trovo in questa situazione molte volte quando leggo la loro documentazione. La differenza può significare i giorni trascorsi in un'attività rispetto alle ore. Ho bisogno di conferme e la documentazione mi dà a malapena spiegazioni, figuriamoci conferme.

La documentazione è affrettata. Non spiega gli eventi, fornisce dettagli vaghi su quando vengono generati errori o sulla natura di tali errori e spesso ci sono diversi modi per realizzare la connettività che possono essere poco chiari. Puoi cavartela e non è completamente inutile, ma è molto ruvido intorno ai bordi. Scoprirai che alcune cose sono lasciate a supposizioni e sperimentazione.