¿Meteor puede manejar correctamente los datos actualizados externamente directamente a la base de datos MongoDB?

Meteor está configurado para conectarse a una base de datos mongo externa . Tiene mongo empaquetado en una aplicación de desarrollo local, pero eso es solo por comodidad y fácil integración.

En producción, siempre tendrá que conectar Meteor a su instancia de Mongo en ejecución usando MONGO_URL variable de entorno .

Bonificación:puede configurar el MONGO_URL incluso en modo de desarrollo para conectarse a una base de datos específica en modo de desarrollo. Tenga en cuenta que puede CRUD todo en esta base de datos, utilícelo con cuidado.

Debajo del capó, Meteor usa el controlador de nodo mongo. Básicamente, puede usar toda la API de este controlador (ver esta publicación para obtener detalles sobre cómo llamar a los métodos nativos de Mongo)

Con el sistema de publicación/suscripción de Meteor básicamente controla qué datos se publican en el cliente. Las publicaciones se ejecutan cada vez que cambian los datos (similar al patrón del observador).

Si todos sus clientes se suscriben a los datos de una colección, obtendrán las actualizaciones, una vez que la colección se actualice. Y ahora vamos a su función más buscada:esto también funciona si alguna fuente externa actualiza estos datos.

También funciona con intervalos de actualización muy rápidos. Trabajé en un proyecto reciente en el que se actualizaron cantidades masivas de datos a través de python en una colección de Mongo-DB. La aplicación Meteor lo escuchó y mostró los datos a los clientes en "tiempo real" (o lo que los usuarios perciben como tiempo real).

Sin embargo, existen algunas trampas y es bueno conocerlas de antemano.

1. Meteor crea documentos con un _id de tipo cadena y no Mongo.ObjectID . Sin embargo, es capaz de leerlo y escribirlo si lo usa correctamente .

2. Meteor envuelve colecciones con una API propia que mejor integra la colección con sus fibers entorno basado. Si necesita usar una funcionalidad más allá, lea aquí y aquí .

3. Cursores devueltos se comportan de forma ligeramente diferente, pero al igual que con las colecciones, también hay todas las funcionalidades nativas disponibles si recibe el cursor de una rawCollection

4. Vuelva a verificar los tipos de datos que usa en sus colecciones. Por ejemplo, manténgase con los mismos tipos de fecha (como ISODate) para que no haya errores no deseados después de una actualización. También hay una contraparte de Meteor para mongoose llamado simpl-schema (paquete npm ) que es una buena manera de mantener la estructura en sus colecciones.

En resumen, si considera la mayor parte de la guía de Meteor y los documentos de API, debería estar en el buen camino, ya que la integración de colecciones actualizadas externamente generalmente funciona muy bien y se trata principalmente de comprender el sistema pub/sub para que funcione.

Editar:

Sí, pero debe tener en cuenta una consulta diferente. Si el documento (creado externamente) tiene el siguiente valor:

{ "_id" : ObjectId("4ecc05e55dd98a436ddcc47c") }

Entonces tienes que cambiar tu consulta (Meteor) de

collection.findOne("4ecc05e55dd98a436ddcc47c") // returns undefined

a

collection.findOne({ "_id" : new Mongo.ObjectID("4ecc05e55dd98a436ddcc47c") }) // returns { _id: ObjectID { _str: '4ecc05e55dd98a436ddcc47c' } }

El mismo patrón funciona para crear documentos. En lugar de

collection.insert({ foo:'bar' })

pasas un ObjectID recién creado:

collection.insert({ foo:'bar', _id: new Mongo.ObjectID() })

Si crea documentos en Meteor con el método anterior, no debería preocuparse por _id siendo una cadena.

Además, los documentos son como deben ser (consulte el puente de formato de datos ). Sin embargo, si encuentra una excepción que no se ha mencionado aquí, no dude en comentar, ya que esto también puede ser importante para otros usuarios.