Jak uporządkować dane wysyłane z serwera do użytkownika?
Użyj wzorca wiadomości . Cóż, już używasz protokołu przesyłania wiadomości, ale mam na myśli strukturę zmian jako wiadomości ... konkretnie zdarzenia. Zmiana po stronie serwera powoduje zdarzenia biznesowe. W twoim scenariuszu opinie klientów są zainteresowane tymi wydarzeniami. Zdarzenia powinny zawierać wszystkie dane istotne dla tej zmiany (niekoniecznie wszystkie dane przeglądania). Strona klienta powinna następnie zaktualizować części widoku, które obsługuje, o dane zdarzenia.
Na przykład, jeśli aktualizowałeś giełdowy giełdowy i zmieniono AAPL, nie chciałbyś zepchnąć wszystkich cen akcji ani nawet wszystkich danych o AAPL (nazwa, opis itp.). Naciskasz tylko AAPL, deltę i nową cenę. Na kliencie zaktualizowałbyś wtedy tylko tę cenę akcji w widoku.
Czy powinienem wysyłać tylko zdarzenia typu „ten zasób został zaktualizowany i należy go ponownie załadować za pośrednictwem wywołania AJAX”, czy też przesłać zaktualizowane dane i zastąpić poprzednie dane załadowane za pomocą początkowych wywołań AJAX?
Nie powiedziałbym ani jednego. Jeśli wysyłasz zdarzenie, śmiało i wyślij wraz z nim odpowiednie dane (nie dane całego obiektu). Nadaj mu nazwę tego rodzaju wydarzenia. (Nazewnictwo i dane istotne dla tego zdarzenia wykraczają poza mechaniczną pracę systemu. Ma to więcej wspólnego z tym, jak modelowana jest logika biznesowa.) Osoby aktualizujące widok muszą wiedzieć, jak przełożyć każde konkretne zdarzenie na precyzyjna zmiana widoku (tj. aktualizuj tylko to, co się zmieniło).
Jak zdefiniować spójny i skalowalny szkielet wysyłanych danych? jest to komunikat o aktualizacji modelu lub komunikat „wystąpił błąd związany z blahblahblah”
Powiedziałbym, że jest to duże, otwarte pytanie, które należy podzielić na kilka innych pytań i opublikować osobno.
Ogólnie jednak system zaplecza powinien tworzyć i wysyłać zdarzenia dotyczące ważnych wydarzeń w firmie. Mogą one pochodzić z zewnętrznych źródeł lub z aktywności w samym zapleczu.
Jak nie wysyłać danych o wszystkim z dowolnego miejsca w wewnętrznej bazie danych?
Użyj wzorca publikowania / subskrypcji . Gdy SPA wczyta nową stronę, która jest zainteresowana otrzymywaniem aktualizacji w czasie rzeczywistym, strona powinna subskrybować tylko te zdarzenia, z których może korzystać, i wywoływać logikę aktualizacji widoku w miarę pojawiania się tych zdarzeń. Prawdopodobnie będziesz potrzebować logiki pub / sub na serwer w celu zmniejszenia obciążenia sieci. Istnieją biblioteki dla publikacji / subskrybentów Websocket, ale nie jestem pewien, jakie są w ekosystemie Railsów.
Jak ograniczyć powielanie logiki biznesowej zarówno po stronie serwera, jak i klienta?
Wygląda na to, że musisz zaktualizować dane widoku zarówno na kliencie, jak i na serwerze. Domyślam się, że potrzebujesz danych widoku po stronie serwera, aby mieć migawkę, aby uruchomić klienta w czasie rzeczywistym. Ponieważ w grę wchodzą dwa języki / platformy (Ruby i Javascript), logika aktualizacji widoku będzie musiała zostać napisana w obu. Oprócz transpilacji (która ma swoje własne problemy), nie widzę rozwiązania tego problemu.
Punkt techniczny: manipulacja danymi (aktualizacja widoku) nie jest logiką biznesową. Jeśli chodzi o sprawdzanie poprawności przypadków użycia, wydaje się to nieuniknione, ponieważ sprawdzanie poprawności klienta jest konieczne dla dobrego doświadczenia użytkownika, ale ostatecznie nie może być zaufane przez serwer.
Oto, w jaki sposób widzę dobrze taką strukturę.
Widoki klienta:
- Żąda obrazu stanu i ostatnio widzianego numeru zdarzenia
- Spowoduje to wstępne wypełnienie widoku, aby klient nie musiał budować od zera.
- Może być przez HTTP GET dla uproszczenia
- Nawiązuje połączenie typu websocket i subskrybuje określone zdarzenia, zaczynając od ostatniego numeru zdarzenia widoku.
- Odbiera zdarzenia przez gniazdo sieciowe i aktualizuje jego widok na podstawie typu / danych zdarzenia.
Polecenia klienta:
- Żądaj zmiany danych (HTTP PUT / POST / DELETE)
- Odpowiedź to tylko sukces lub porażka + błąd
- (Zdarzenia wygenerowane przez zmianę przejdą przez websocket i uruchomią aktualizację widoku.)
Po stronie serwera można faktycznie podzielić na kilka komponentów o ograniczonej odpowiedzialności. Taki, który po prostu przetwarza przychodzące żądania i tworzy zdarzenia. Inny może zarządzać subskrypcjami klientów, nasłuchiwać zdarzeń (powiedzmy w toku) i przekazywać odpowiednie zdarzenia subskrybentom. Możesz mieć jedną trzecią, która nasłuchuje zdarzeń i aktualizuje widoki po stronie serwera - być może dzieje się to nawet zanim subskrybenci otrzymają zdarzenia.
To, co opisałem, to forma CQRS + Messaging i typowa strategia rozwiązywania problemów, z którymi się borykasz .
Nie włączyłem w ten opis Sourcing zdarzeń, ponieważ nie jestem pewien, czy jest to coś, co chcesz podjąć, czy też potrzebujesz go koniecznie. Ale jest to powiązany wzór.