2013-06-28 18 views
6

To jest pytanie dla tych, którzy znają architekturę Meteora.Jak zaprojektować inteligentny pakiet meteorytów, aby w przejrzysty sposób oddzielić aplikację na różne instancje?

Próbuję zaprojektować inteligentny pakiet, który może przezroczyście uruchomić kilka "kopii" aplikacji Meteor. Oznacza to, że biorąc pod uwagę istniejącą aplikację Meteor i kilka wstępnie zdefiniowanych grup użytkowników, pakiet może półautomatycznie "segregować" aplikację - uruchamiać ją w sposób, w jaki dla każdej grupy użytkowników, wydaje się, że tylko ci użytkownicy używają aplikacja.

Rozumiem, że ta funkcja może być zaprojektowana na zamówienie dla dowolnej aplikacji. Jednak szukam najbardziej prostego sposobu na inteligentny pakiet, aby zapewnić tę funkcjonalność w stosunku do każdej istniejącej aplikacji, biorąc pod uwagę korzystanie z Meteor's Collection s i wszystkich. W związku z tym powinien spełniać mniej lub więcej następujących wymagań:

  • Powinien być równie skuteczny jak zwykła aplikacja Meteor.
  • Konwersja istniejącej aplikacji Meteor do korzystania z tego systemu powinna wymagać minimalnej modyfikacji kodu.
  • Pakiet nie powinien modyfikować ani zastępować Meteora i być względnie przyszłościowy.

Oto kilka podejść i odpowiadające im wady Myślałem o tego problemu:

  • korzystać ze wszystkich zbiorów regularnej aplikacji Meteor i oznaczyć każdy dokument z dodatkowym identyfikatorem reprezentujący grupę użytkownik jest zalogowany. Publikacje/subskrypcje dla każdego użytkownika pobierają tylko dokumenty o tym samym identyfikatorze grupy.
  • Przesłoń Meteor.Collection (lub zaimplementuj identyczny interfejs) w sposób, który informuje o tych różnych grupach, a z perspektywy klienta zachowuje się tak, jakby grupa użytkownika była całą aplikacją.

Szukam dobrych pomysłów od kogoś, kto naprawdę zna system Meteora. Jak zaprojektować tę funkcjonalność w taki sposób, aby zdecydowana większość aplikacji Meteor mogła być łatwo przekonwertowana do pracy z nią (tj. Unikała szalonych hacków, które są bardzo kruche), a jednocześnie jest prosta i wydajna w implementacji na Meteor?

(Jeśli jesteś guru Meteor w obszarze Nowego Jorku, byłbym szczęśliwy, że cię na obiad, aby omówić to!)

+0

Znalazłeś jakieś dobre odpowiedzi na to pytanie? A może nawet wypróbowałeś je w praktyce? – tuomassalo

+1

@tuomassalo Sam je budowałem; zobacz https://github.com/HarvardEconCS/turkserver-meteor dla implementacji, która stanie się bardziej zaawansowana w ciągu następnych kilku miesięcy. –

Odpowiedz

6

Wziąłem moją pracę nad tym problemem i wyciągnął go na zewnątrz do Inteligentny pakiet Meteora. Spełnia wszystkie wymagania, które zauważyłem w moim pytaniu. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją i instrukcjami.

https://github.com/mizzao/meteor-partitioner

Ponieważ używam tego w praktyce już kod jest dość stabilna i posiada dobry zestaw testów. Komentarze i składki są mile widziane.

Przykładowy pakiet, który korzysta z tego jest następujący:

https://github.com/HarvardEconCS/turkserver-meteor

+0

Cześć Andrew, wygląda to naprawdę fajnie i dzięki za pracę nad tym. Próbuję w pełni objąć głowę tą koncepcją kolekcjonowania partycji. Czy sądzisz, że jest to sposób na przejście na partycję ?, aplikacja internetowa podobna do Slacka - gdzie możesz skonfigurować własną domenę, a następnie dołączyć do niej? Lub aplikacja internetowa z siecią szkół (jedną z nich jest Harvard), gdzie mogą łączyć się tylko osoby z określonym adresem e-mail ([email protected])? Jak podszedłbyś do tego typu architektury? Chciałbym z tobą porozmawiać o tym, jeśli masz pomysły! – mousesports

+0

Jest to z pewnością lekki system partycjonowania, prawdopodobnie nie użyłbym tego do podziału ogromnego systemu z mnóstwem danych, które tak naprawdę nie muszą być uruchomione na tych samych serwerach itp. –

+0

OK, dziękuję. Chciałbym wybrać swój mózg, w jaki sposób możesz podejść do tego, jeśli i kiedy masz czas. – mousesports