Kan Meteor op de juiste manier omgaan met gegevens die extern worden bijgewerkt, rechtstreeks naar de MongoDB-database?

Meteor is geconfigureerd om verbinden met een externe mongo-database . Je hebt mongo verpakt in een lokale ontwikkelings-app, maar dat is alleen voor comfort en gemakkelijke integratie.

In productie moet je Meteor altijd verbinden met je draaiende Mongo-instantie met behulp van de MONGO_URL omgevingsvariabele .

Bonus:u kunt de MONGO_URL . instellen zelfs in dev-modus om verbinding te maken met een specifieke db in dev-modus. Houd er rekening mee dat je alles op deze db kunt CRUDeren, gebruik het met zorg.

Onder de motorkap gebruikt Meteor de node mongo-driver. U kunt in principe alle API van deze driver gebruiken (zie dit bericht voor details over het aanroepen van native Mongo-methoden)

Met Meteor's publicatie-/abonnementssysteem u bepaalt in feite welke gegevens aan de klant worden gepubliceerd. Elke keer dat de gegevens veranderen, worden er publicaties uitgevoerd (vergelijkbaar met het patroon van de waarnemer).

Als al uw klanten zich abonneren op de gegevens van een collectie, krijgen ze de updates zodra de collectie wordt bijgewerkt. En nu kom je bij je meest gewilde functie:dit werkt ook als deze gegevens worden bijgewerkt door een externe bron.

Het werkt ook met zeer snelle update-intervallen. Ik heb aan een recent project gewerkt waarbij enorme hoeveelheden gegevens zijn bijgewerkt via python op een Mongo-DB-verzameling. De Meteor-app luisterde ernaar en toonde de gegevens aan de klanten in "realtime" (of wat gebruikers als realtime ervaren).

Er zijn echter enkele valkuilen en het is goed om deze van tevoren te kennen.

Meteor maakt documenten met een _id van type string en niet Mongo.ObjectID . Het kan het echter lezen en schrijven als u het correct gebruikt .

Meteor omhult collecties met een eigen API die de collectie het beste integreert met zijn fibers gebaseerde omgeving. Als je meer functionaliteit nodig hebt, lees dan hier en hier .
Geretourneerde cursors gedragen zich iets anders, maar net als bij Collections zijn er ook alle native functionaliteiten beschikbaar als u de cursor ontvangt van een rawCollection
Controleer nogmaals de gegevenstypen die u voor uw collecties gebruikt. Blijf bijvoorbeeld bij dezelfde datumtypen (zoals ISODate), zodat er geen onbedoelde fouten zijn na een update. Er is ook een Meteor-tegenhanger van mongoose genaamd simpl-schema (npm-pakket ), wat een goede manier is om structuur in uw collecties te houden.

Samengevat, als je het meeste van de Meteor-gids en API-documenten in overweging neemt, zou je op een goed spoor moeten zijn, aangezien de integratie van extern bijgewerkte collecties meestal erg goed verloopt en het vooral gaat om het begrijpen van het pub/sub-systeem om het te laten werken.

Bewerken:

Ja, dat doet het, maar u moet op de hoogte zijn van een andere vraag. Als het (extern gemaakte) document de volgende waarde heeft:

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

Dan moet je je (Meteor)query wijzigen van

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

naar

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

Hetzelfde patroon werkt voor het maken van documenten. In plaats van

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

u geeft een nieuw aangemaakte ObjectID door:

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

Als u documenten in Meteor maakt met de bovenstaande methode, hoeft u zich geen zorgen te maken over _id een String zijn.

Daarnaast zijn documenten zoals ze zouden moeten zijn (zie de dataformaatbrug ). Als je echter een uitzondering hebt gevonden die hier niet is vermeld, kun je reageren, want dit kan ook belangrijk zijn voor andere gebruikers.