Meteor est configuré pour se connecter à une base de données mongo externe . Vous avez mongo emballé sur une application de développement local, mais c'est juste pour le confort et l'intégration facile.
En production, vous devrez toujours connecter Meteor à votre instance Mongo en cours d'exécution en utilisant le MONGO_URL variable d'environnement
.
Bonus :vous pouvez définir le MONGO_URL même en mode dev pour se connecter à une base de données spécifique en mode dev. Sachez que vous pouvez CRUD tout sur cette base de données, utilisez-le avec précaution.
Sous le capot, Meteor utilise le pilote node mongo. Vous êtes en principe capable d'utiliser toute l'API de ce pilote (voir ce message pour plus de détails sur la façon d'appeler les méthodes natives Mongo)
Avec le système de publication/abonnement de Meteor vous contrôlez essentiellement les données publiées sur le client. Les publications s'exécutent chaque fois que les données changent (similaire au modèle d'observateur).
Si tous vos clients souscrivent aux données d'une collection, ils recevront les mises à jour, une fois la collection mise à jour. Et maintenant, venez à votre fonctionnalité la plus recherchée :cela fonctionne également si ces données sont mises à jour par une source externe.
Il fonctionne également avec des intervalles de mise à jour très rapides. J'ai travaillé sur un projet récent où des quantités massives de données ont été mises à jour via python sur une collection Mongo-DB. L'application Meteor l'a écouté et a affiché les données aux clients en "temps réel" (ou ce que les utilisateurs perçoivent comme temps réel).
Cependant, il y a quelques pièges et il est bon de les connaître à l'avance.
-
Meteor crée des documents avec un
_idde type string et nonMongo.ObjectID. Cependant il est capable de le lire et de l'écrire si vous l'utilisez correctement . -
Meteor enveloppe les collections avec une propre API qui intègre le mieux la collection avec ses
fibersenvironnement basé. Si vous avez besoin d'utiliser des fonctionnalités au-delà, veuillez lire ici et ici . -
Curseurs renvoyés se comporte légèrement différemment mais comme pour les collections, toutes les fonctionnalités natives sont également disponibles si vous recevez le curseur d'une
rawCollection -
Vérifiez les types de données que vous utilisez dans vos collections. Par exemple, conservez les mêmes types de date (comme ISODate) afin qu'il n'y ait pas d'erreurs involontaires après une mise à jour. Il existe également un équivalent Meteor de
mongoosenommésimpl-schema(paquet npm ) qui est un bon moyen de structurer vos collections.
En résumé, si vous considérez la plupart des documents du guide Meteor et de l'API, vous devriez être sur la bonne voie car l'intégration de collections mises à jour en externe fonctionne généralement très bien et il s'agit principalement de comprendre le système pub/sub pour le faire fonctionner.
Modifier :
Oui, mais vous devez être conscient d'une requête différente. Si le document (créé en externe) a la valeur suivante :
{ "_id" : ObjectId("4ecc05e55dd98a436ddcc47c") }
Ensuite, vous devez modifier votre requête (Meteor) à partir de
collection.findOne("4ecc05e55dd98a436ddcc47c") // returns undefined
à
collection.findOne({ "_id" : new Mongo.ObjectID("4ecc05e55dd98a436ddcc47c") }) // returns { _id: ObjectID { _str: '4ecc05e55dd98a436ddcc47c' } }
Le même modèle fonctionne pour la création de documents. Au lieu de
collection.insert({ foo:'bar' })
vous passez un ObjectID nouvellement créé :
collection.insert({ foo:'bar', _id: new Mongo.ObjectID() })
Si vous créez des documents dans Meteor avec la méthode ci-dessus, vous ne devriez pas avoir à vous soucier de _id étant une chaîne.
De plus, les documents sont tels qu'ils devraient être (voir le pont de format de données ). Cependant, si vous avez trouvé une exception qui n'a pas été mentionnée ici, n'hésitez pas à commenter car cela peut également être important pour d'autres utilisateurs.
