Strona zamówienia może potrzebować aktualizacji w tym samym czasie co Twoja baza danych. Webhook może wywołać zmianę w bazie. Twój serwer może następnie opublikować wynikowy stan na podłączonych ekranach.
Bird Realtime dostarcza aktualizacje przez WebSockety.
Czym są kanały, członkowie i połączenia?
Kanał grupuje subskrypcje. Połączenie to jeden otwarty WebSocket. Członek to uwierzytelniona tożsamość współdzielona z innymi subskrybentami.
Kanał presence udostępnia informację, którzy członkowie subskrybują. Jeden członek może korzystać z kilku połączeń, na przykład z osobnych kart przeglądarki.
Bird tworzy kanał, gdy jego pierwsze połączenie zasubskrybuje, i usuwa go, gdy ostatnie połączenie odejdzie. Publikujesz pod nazwą kanału bez tworzenia osobnego zasobu kanału.
Każde połączenie otrzymuje identyfikator. Twój backend używa go do zatwierdzenia prywatnej subskrypcji. Publikacja może wykluczyć to połączenie, aby uniknąć powielenia własnej aktualizacji.
Jeśli jeden członek otworzy trzy karty, mogą one utworzyć trzy połączenia pod jedną tożsamością członka. Presence zgłasza dołączenie członka przy pierwszym połączeniu i opuszczenie po zamknięciu ostatniego połączenia. Zamknięcie środkowej karty nie usuwa więc tego członka z listy.
Kto może subskrybować?
Prefiks kanału określa, czy subskrypcja wymaga autoryzacji z Twojego backendu.
Wybierasz nazwę kanału Bird o długości od 1 do 164 znaków, używając liter, cyfr i _ - = @ , . ;. Uwzględnij prefiks w tej długości, aby wygenerowana nazwa prywatna mieściła się w limicie.
| Prefiks nazwy | Dostęp |
|---|---|
| Brak prefiksu private ani presence | Publiczny dla klientów posiadających klucz aplikacji. |
private- | Twój backend zatwierdza i podpisuje każdą subskrypcję. |
presence- | Twój backend zatwierdza subskrypcję i dostarcza tożsamość członka współdzieloną z subskrybentami. |
private-encrypted- | Prywatny dostęp z zawartością zdarzeń szyfrowaną kluczem, który kontrolujesz. |
Klucz aplikacji jest widoczny w kodzie klienta, więc niejasna nazwa publicznego kanału nie chroni poufnych danych. Przechowuj sekret aplikacji na swoim serwerze i używaj go do podpisywania zatwierdzeń subskrypcji.
Przy prywatnej subskrypcji klient wysyła identyfikator połączenia i nazwę kanału do Twojego endpointu autoryzacji. Twój serwer sprawdza dostęp przed zwróceniem podpisu. Ten endpoint autoryzuje dostęp. Nie otrzymuje każdego opublikowanego zdarzenia, jak robiłby to webhook.
Co ta różnica oznacza w praktyce?
Używaj webhooków do odtwarzalnej pracy na swoim serwerze. Używaj pub/sub do aktualizacji podłączonych klientów.
Webhook Bird wysyła zdarzenie do endpointu HTTPS, który obsługujesz. Ponawianie obejmuje około 27,5 godziny, z odstępami korygowanymi losową zmiennością, przeciążeniem odbiorcy i żądanymi opóźnieniami. To okno daje Twojemu odbiorcy czas na odzyskanie sprawności. Ponowne odtwarzanie pominiętych zdarzeń może odzyskać dostarczenia, które nie powiodły się.
Kanał Realtime wysyła opublikowane zdarzenie do subskrybujących klientów. Rozłączony klient może je pominąć. Kanał cache może dostarczyć najnowsze zdarzenie nowemu subskrybentowi, dopóki to zdarzenie pozostaje w pamięci podręcznej. Nie przechowuje pośredniej historii zdarzeń.
Przetwarzanie poufnych danych po stronie serwera pozostaw za odbiornikiem webhooka. Publikuj tylko stan, który mogą widzieć autoryzowani klienci kanału.
Typy zdarzeń webhooków pochodzą z katalogu Bird, na przykład email.delivered. W Realtime wybierasz nazwę zdarzenia swojej aplikacji podczas publikowania. Nazwa event przyjmuje od 1 do 200 znaków. Prefiksy bird: i bird_internal: są zarezerwowane i nie mogą nazywać zdarzeń Twojej aplikacji.
Klienci otrzymują też zdarzenia protokołu dotyczące powodzenia subskrypcji, zmian członków i liczby połączeń. Te zdarzenia opisują samo połączenie lub kanał, a nie zamówienie czy wiadomość Twojej aplikacji.
Jak ich używać razem?
Użyj zapisanego zdarzenia z webhooka, aby wywołać aktualizację Realtime dla podłączonych klientów.
Odbierz zdarzenie biznesowe na swoim serwerze. Zaktualizuj trwały stan przed publikacją. Następnie opublikuj stan, którego potrzebują podłączeni klienci.
W przypadku strony zamówienia webhook może wywołać aktualizację bazy danych. Twój serwer publikuje następnie zaktualizowany stan zamówienia, dzięki czemu strona klienta zmienia się bez odświeżania.
Zadbaj, aby stan bazy danych był odczytywalny po ponownym połączeniu, ponieważ rozłączony klient może pominąć publikacje. Webhooki, polling lub streaming porównuje opcje odzyskiwania.
Realtime ma również własne webhooki dotyczące zajętości kanałów oraz dołączeń i odejść członków. Konfiguruj je przez dashboard, a nie przez publiczne webhooki API.
Przegląd Realtime opisuje połączenia klientów. Webhooki opisują żądania dostarczane do Twojego serwera.
W skrócie
Kanał może mieć wielu subskrybentów.
Żądanie webhooka trafia do jednego zarejestrowanego endpointu. Publikacja trafia do klientów subskrybujących dany kanał.
Prywatne subskrypcje wymagają zatwierdzenia po stronie backendu.
Klucz aplikacji jest widoczny w kodzie klienta. Prefiksy private i presence wymagają podpisu z Twojego serwera.
Członkowie mogą mieć kilka połączeń.
Członek korzystający z trzech kart dołącza do presence przy pierwszym połączeniu i opuszcza go po zamknięciu ostatniego połączenia.
Połącz odzyskiwanie dostarczania z podłączonym widokiem.
Używaj odzyskiwania webhooków do zdarzeń serwerowych i zapisanego stanu, aby przywrócić widok Realtime po rozłączeniu.