Aktualizacje tłumaczeń w czasie rzeczywistym powinny być przydatne, a nie wymagane

Obserwowanie, jak tłumaczenie przechodzi od queued do working do ready, jest przydatne. Zespoły mogą śledzić postęp bez odświeżania, szybko otwierać ukończoną pracę i zauważyć nieudane żądanie, gdy wydanie jest jeszcze aktywne.

Ale aktualizacje na żywo są funkcją prezentacyjną. Nie powinny być mechanizmem, który sprawia, że przepływ pracy działa poprawnie.

Najpierw trwały stan

Baza danych i system zadań powinny być źródłem stanu tłumaczenia. Każda zmiana etapu musi zostać zapisana niezależnie od tego, czy przeglądarka jest połączona:

• żądanie dodane do kolejki
• tłumaczenie rozpoczęte i zakończone
• push rozpoczęty i zakończony
• publikacja rozpoczęta i zakończona
• zdarzenia błędu i ponowienia próby

Zdarzenie realtime może ogłosić tę trwałą zmianę. Nie powinno być jedynym zapisem, że zmiana nastąpiła.

To rozróżnienie chroni użytkowników, którzy zamkną kartę, stracą dostęp do sieci lub pracują w środowisku, w którym infrastruktura websocket jest wyłączona.

Realtime ma koszt operacyjny

Broadcasting wprowadza więcej ruchomych części: usługę websocket, autoryzację połączeń, konfigurację kanałów, obsługę proxy i zachowanie ponownego łączenia w przeglądarce.

Dla zespołów, które potrzebują koordynacji na żywo, ten koszt może być uzasadniony. Dla mniejszego wdrożenia zwykły polling może być prostszy i całkowicie wystarczający.

Uczynienie realtime opcjonalnym pozwala każdemu środowisku wybrać profil operacyjny, który może obsłużyć, bez utraty podstawowego działania tłumaczeń.

Zaprojektuj łagodne rozwiązanie zapasowe

Interfejs użytkownika powinien osiągać ten sam stan końcowy dzięki zdarzeniom realtime lub okresowemu odświeżaniu.

Praktyczne podejście to:

1. wczytaj bieżący trwały stan
2. subskrybuj odpowiednie zdarzenia, gdy realtime jest włączone
3. scalaj przychodzące aktualizacje według ID żądania i wersji
4. odpytuj w umiarkowanych odstępach, dopóki trwa aktywna praca
5. zatrzymaj częste odpytywanie, gdy partia osiągnie stan terminalny

Realtime sprawia, że ekran wydaje się natychmiastowy. Polling domyka luki po ponownych połączeniach i zapewnia rozwiązanie zapasowe.

Te dwie ścieżki nie powinny tworzyć konkurujących zasad statusu.

Unikaj zamieniania aktualizacji w szum

Nie każde wewnętrzne zdarzenie należy do interfejsu. Broadcastowanie każdego tokenu, heartbeat workera lub pośredniego zapisu może sprawić, że strona będzie niestabilna, i zwiększyć obciążenie infrastruktury.

Użytkownicy zwykle potrzebują istotnych zmian etapów i zaktualizowanych liczników. Grupowanie szybkich zmian niskiego poziomu w mniejszy zestaw trwałych kamieni milowych sprawia, że doświadczenie pozostaje spokojne i łatwe do szybkiego przejrzenia.

Ta sama zasada dotyczy powiadomień. Ukończona partia może zasługiwać na uwagę. Każdy ukończony locale prawdopodobnie nie.

Testuj cichą ścieżkę

Łatwo jest testować z włączonym realtime i zakładać, że rozwiązanie zapasowe działa. Niezawodność wymaga przeciwnego ćwiczenia:

• wyłącz broadcasting
• uruchom partię dla wielu locale
• opuść stronę i wróć na nią
• potwierdź, że postęp się aktualizuje
• ponów nieudane żądanie
• zweryfikuj końcowe liczniki i dostępne działania

Jeśli ta ścieżka działa, realtime jest ulepszeniem zamiast ukrytej zależności.

Wniosek

Aktualizacje na żywo usprawniają operacje tłumaczeniowe, gdy opierają się na trwałym stanie.

Najpierw zapisuj każdą zmianę, skonfiguruj broadcasting jako opcjonalny i zachowaj wyważone rozwiązanie zapasowe oparte na pollingu. Przepływ pracy powinien pozostać godny zaufania, nawet gdy najbardziej bezpośredni kanał dostarczania jest niedostępny.