Webhooks vs. polling

Quando costruiamo applicazioni Web, spesso abbiamo più servizi. Nella stragrande maggioranza dei casi, consistono di molti servizi Web diversi che lavorano insieme. In questo tipo di applicazione Web che consiste di più servizi, come trasmettere i dati è qualcosa che ogni sviluppatore deve considerare.

Quando si tratta di risolvere questo problema, due approcci sono diventati mainstream: webhooks e polling. Ogni metodo fornisce un modo unico per recuperare e consegnare i dati da un servizio a un altro. Scegliere uno rispetto all'altro può avere un grande impatto sull'efficienza della tua applicazione, sulle capacità in tempo reale e sull'esperienza complessiva dell'utente. Questo articolo confronterà webhooks e polling, analizzerà i vantaggi e gli svantaggi di ciascun approccio e discuterà quando utilizzare l'uno o l'altro.

Cos'è il polling?#

Il polling (spesso indicato come API polling) è il processo in cui un client richiede dati specifici a intervalli regolari (diciamo, ogni x secondi), e il server risponde con i dati richiesti.

Pensalo come chiedere: "Ci sono nuovi dati?" a intervalli regolari. Il polling può essere implementato tramite richieste HTTP, dove il client invia una richiesta GET al server e il server risponde con i dati richiesti.

Immagina che John abbia costruito un prodotto di documentazione AI chiamato Doc.AI e utilizza Logto per la gestione dell'identità degli utenti.

Frank è un utente che si è registrato con il prodotto di John e ha creato il proprio account personale. Un giorno, Frank si unisce a un workspace creato dal suo amico David. In quel momento, John vuole inviare un'email a Frank per chiedergli di attivare l'Autenticazione a Due Fattori (MFA) per aumentare la sicurezza del suo account prima che John gli conceda l'accesso a risorse sensibili aggiuntive.

Il backend del prodotto di John deve continuare a fare polling delle API rilevanti per sapere quando Frank si unisce al workspace di David.

Cos'è un webhook?#

Un webhook (ossia "HTTP callback") è un meccanismo per la comunicazione dei dati in tempo reale, mediante il quale un server invia dati a un client quando si verifica un evento. Piuttosto che un client richieda dati, un webhook li invia al client ogni volta che c'è un aggiornamento.

Pensalo come una casella di posta per la tua applicazione. Quando si verificano determinati eventi - per esempio, un nuovo utente si registra o viene effettuato un pagamento - un webhook inserirà un messaggio nella casella di posta per far sapere alla tua applicazione cosa sta succedendo.

Continuiamo con il nostro esempio di Doc.AI che abbiamo usato in precedenza per spiegare il polling. Ecco come apparirà il diagramma di sequenza se utilizziamo webhooks per scoprire se Frank si è unito al workspace di David:

Differenze importanti#

• Origine della richiesta Il polling è iniziato dal client (nel nostro esempio, Doc.AI è il client e Logto è il server) e il webhook è attivato da un evento ed è avviato dal server.
• Consumo di risorse Il polling spreca risorse computazionali poiché invia richieste a intervalli regolari, risultando in un'efficienza bassa delle risorse computazionali. D'altra parte, il webhook è avviato dal server "su richiesta". Rispetto al polling, sia il client che il server consumano molte meno risorse.
• Tempistica Il polling è avviato dal client, quindi il client può controllare la tempistica di acquisizione dei dati; Tuttavia, il webhook è avviato dal server e il client può solo ricevere e elaborare i dati. Tuttavia, a causa dei diversi meccanismi dei due, il webhook può raggiungere una sincronizzazione dei dati in tempo reale, cosa che non può essere raggiunto con il polling.

Quale dovrei scegliere?#

Basato sui meccanismi di polling e webhooks, la pratica comune è scegliere il polling solo quando i dati vengono aggiornati frequentemente e i requisiti di tempo reale per i dati non sono stringenti. In altri casi, i webhooks sarebbero una scelta migliore.

Tuttavia, quando si sceglie di utilizzare i webhooks, gli sviluppatori devono prestare attenzione ai seguenti aspetti:

1. Se il sistema dipende molto dai dati acquisiti, è necessario considerare di avere un piano di backup per acquisire i dati quando il webhook fallisce e i dati non possono essere sincronizzati, incluso ma non limitato al polling o richiedere che il webhook abbia un meccanismo di reinvio, ecc.
2. Nel endpoint lato client che riceve i webhooks, dovrebbero essere applicati la segretezza delle API e la verifica della firma del contenuto, ecc. per prevenire attacchi da parte di hacker che fingono di essere il webhook.
3. Poiché il webhook potrebbe inviare richieste duplicate, è necessario un trattamento corrispondente per evitare duplicazione dei dati e incoerenza.

Logto, come una soluzione di identificazione utente estremamente popolare, offre numerosi scenari webhook e un'eccellente sicurezza. Utilizzando Logto come sistema di identità per i tuoi prodotti, può essere facilmente integrato e adattato a vari scenari applicativi.