Czy Meteor może poprawnie obsługiwać dane aktualizowane zewnętrznie bezpośrednio do bazy danych MongoDB?

Meteor jest skonfigurowany do połączenia z zewnętrzną bazą danych mongo . Masz mongo spakowane w lokalnej aplikacji programistycznej, ale to tylko dla wygody i łatwej integracji.

W środowisku produkcyjnym zawsze będziesz musiał połączyć Meteor z uruchomioną instancją Mongo za pomocą MONGO_URL zmienna środowiskowa .

Bonus:możesz ustawić MONGO_URL nawet w trybie deweloperskim, aby połączyć się z określoną bazą danych w trybie deweloperskim. Pamiętaj, że możesz CRUD wszystko na tej bazie danych, używaj ostrożnie.

Pod maską Meteor używa sterownika węzła mongo. Zasadniczo jesteś w stanie korzystać z całego interfejsu API tego sterownika (zobacz ten post aby uzyskać szczegółowe informacje na temat wywoływania natywnych metod Mongo)

Z systemem publikacji/subskrypcji firmy Meteor zasadniczo kontrolujesz, jakie dane są publikowane dla klienta. Publikacje są uruchamiane za każdym razem, gdy zmieniają się dane (podobnie do wzorca obserwatora).

Jeśli wszyscy Twoi klienci subskrybują dane kolekcji, otrzymają aktualizacje po aktualizacji kolekcji. A teraz przechodzimy do najbardziej pożądanej funkcji:działa to również, jeśli te dane są aktualizowane przez jakieś zewnętrzne źródło.

Działa również z bardzo szybkimi interwałami aktualizacji. Pracowałem nad ostatnim projektem, w którym ogromne ilości danych zostały zaktualizowane za pomocą Pythona w kolekcji Mongo-DB. Aplikacja Meteor słuchała go i wyświetlała dane klientom „w czasie rzeczywistym” (lub w tym, co użytkownicy postrzegają jako czas rzeczywisty).

Istnieją jednak pewne pułapki i dobrze jest je znać z wyprzedzeniem.

1. Meteor tworzy dokumenty z _id typu string, a nie Mongo.ObjectID . Jest jednak w stanie go odczytać i zapisać jeśli używasz go poprawnie .

2. Meteor otacza kolekcje własnym interfejsem API która najlepiej integruje kolekcję z jej fibers oparte na środowisku. Jeśli chcesz korzystać z innych funkcji, przeczytaj tutaj i tutaj .

3. Kursory zwrócone zachowują się nieco inaczej, ale tak jak w przypadku Kolekcji, dostępne są również wszystkie natywne funkcje, jeśli otrzymasz kursor z rawCollection

4. Dokładnie sprawdź typy danych, których używasz w swoich kolekcjach. Na przykład trzymaj się tych samych typów dat (takich jak ISODate), aby nie było niezamierzonych błędów po aktualizacji. Istnieje również odpowiednik Meteor dla mongoose nazwany simpl-schema (pakiet npm ), co jest dobrym sposobem na zachowanie struktury kolekcji.

Podsumowując, jeśli weźmiesz pod uwagę większość przewodnika Meteor i dokumentacji API, powinieneś być na dobrej drodze, ponieważ integracja zaktualizowanych zewnętrznie kolekcji zwykle przebiega bardzo dobrze i polega głównie na zrozumieniu systemu pub/sub, aby mógł działać.

Edytuj:

Tak, ale musisz zdawać sobie sprawę z innego zapytania. Jeśli (utworzony zewnętrznie) dokument ma następującą wartość:

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

Następnie musisz zmienić zapytanie (Meteor) z

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

do

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

Ten sam wzór działa przy tworzeniu dokumentów. Zamiast

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

przekazujesz nowo utworzony ObjectID:

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

Jeśli tworzysz dokumenty w Meteor za pomocą powyższej metody, nie musisz się martwić o _id będąc ciągiem.

Poza tym dokumenty są takie, jakie powinny być (zobacz mostek formatu danych ). Jeśli jednak znalazłeś wyjątek, który nie został tutaj wymieniony, możesz skomentować, ponieważ może to być ważne również dla innych użytkowników.