Una pagina ordine può aver bisogno di un aggiornamento nello stesso momento del tuo database. Un webhook può attivare la modifica nel database. Il tuo server può quindi pubblicare lo stato risultante sugli schermi connessi.
Bird Realtime consegna aggiornamenti tramite WebSocket.
Cosa sono canali, membri e connessioni?
Un canale raggruppa le sottoscrizioni. Una connessione è un WebSocket aperto. Un membro è un'identità autenticata condivisa con gli altri sottoscrittori.
Un canale presence mostra quali membri sono iscritti. Un membro può usare più connessioni, ad esempio schede del browser separate.
Bird crea un canale quando la sua prima connessione si iscrive e lo rimuove dopo che l'ultima esce. Pubblichi sul nome del canale senza creare una risorsa canale separata.
Ogni connessione riceve un identificativo. Il tuo backend lo usa per approvare una sottoscrizione privata. Una pubblicazione può escludere quella connessione per evitare di riecheggiarle il suo stesso aggiornamento.
Se un membro apre tre schede, quelle schede possono creare tre connessioni sotto un'unica identità membro. Presence segnala l'ingresso del membro alla prima connessione e l'uscita dopo la chiusura dell'ultima connessione. Chiudere la scheda intermedia quindi non rimuove quel membro dalla lista.
Chi è autorizzato a iscriversi?
Il prefisso del canale determina se una sottoscrizione necessita di autorizzazione dal tuo backend.
Scegli un nome canale Bird da 1 a 164 caratteri, usando lettere, cifre e _ - = @ , . ;. Includi il prefisso in quella lunghezza in modo che un nome privato generato resti entro il limite.
| Prefisso del nome | Accesso |
|---|---|
| Nessun prefisso private o presence | Pubblico per i client che possiedono la app key. |
private- | Il tuo backend approva e firma ogni sottoscrizione. |
presence- | Il tuo backend approva la sottoscrizione e fornisce l'identità membro condivisa con i sottoscrittori. |
private-encrypted- | Accesso privato con contenuti degli eventi cifrati tramite una chiave che controlli tu. |
La app key è visibile nel codice client, quindi un nome di canale pubblico poco conosciuto non protegge dati riservati. Tieni la app secret sul tuo server e usala per firmare le approvazioni delle sottoscrizioni.
Per una sottoscrizione privata, il client invia il proprio identificativo di connessione e il nome del canale al tuo endpoint di autorizzazione. Il tuo server verifica l'accesso prima di restituire la firma. Quell'endpoint autorizza l'accesso. Non riceve ogni evento pubblicato come farebbe un webhook.
Cosa cambia in pratica?
Usa i webhook per operazioni recuperabili sul tuo server. Usa il pub/sub per aggiornamenti ai client connessi.
Un webhook Bird invia un evento a un endpoint HTTPS che gestisci tu. I tentativi coprono circa 27,5 ore, con attese adattate da variazione casuale, sovraccarico del ricevente e ritardi richiesti. Quella finestra dà al tuo ricevente il tempo di ripristinarsi. Il replay degli eventi mancati può recuperare le consegne rimaste senza successo.
Un canale Realtime invia il tuo evento pubblicato ai client iscritti. Un client disconnesso può perderlo. Un canale cache può fornire il suo ultimo evento a un nuovo sottoscrittore finché quell'evento resta in cache. Non conserva la cronologia degli eventi intermedi.
Mantieni l'elaborazione riservata lato server dietro il tuo ricevente webhook. Pubblica solo lo stato che i client autorizzati del canale possono vedere.
I tipi di evento webhook provengono dal catalogo di Bird, ad esempio email.delivered. Con Realtime, scegli il nome dell'evento della tua applicazione al momento della pubblicazione. Il nome event accetta da 1 a 200 caratteri. I prefissi bird: e bird_internal: sono riservati e non possono essere usati per i tuoi eventi applicativi.
I client ricevono anche eventi di protocollo relativi a successo della sottoscrizione, cambiamenti dei membri e conteggio delle connessioni. Questi eventi descrivono la connessione o il canale stesso, non l'ordine o il messaggio della tua applicazione.
Come li uso insieme?
Usa l'evento memorizzato dal webhook per generare un aggiornamento Realtime per i client connessi.
Ricevi l'evento di business sul tuo server. Aggiorna lo stato durevole prima di pubblicare. Poi pubblica lo stato di cui hanno bisogno i client connessi.
Per una pagina ordine, il webhook può attivare un aggiornamento del database. Il tuo server pubblica poi lo stato aggiornato dell'ordine in modo che la pagina del cliente cambi senza un refresh.
Mantieni quello stato del database leggibile dopo la riconnessione, perché un client disconnesso può perdere le pubblicazioni. Webhook, polling o streaming confronta le opzioni di recupero.
Realtime ha anche i propri webhook per l'occupazione dei canali e gli arrivi o le partenze dei membri. Configurali dalla dashboard anziché dall'API dei webhook pubblici.
Panoramica di Realtime tratta le connessioni client. Webhook tratta le richieste consegnate al tuo server.
In breve
Un canale può avere molti sottoscrittori.
Una richiesta webhook va a un singolo endpoint registrato. Una pubblicazione va ai client iscritti al suo canale.
Le sottoscrizioni private richiedono l'approvazione del backend.
La app key è visibile nel codice client. I prefissi private e presence richiedono una firma dal tuo server.
I membri possono avere più connessioni.
Un membro che usa tre schede entra in presence alla prima connessione e esce dopo la chiusura dell'ultima connessione.
Combina il recupero delle consegne con una vista connessa.
Usa il recupero webhook per gli eventi server e lo stato salvato per ripristinare una vista Realtime dopo una disconnessione.