Ho sempre desiderato fare una chat in tempo reale.

L'ho fatto anni fa in PHP + Ajax + Mysql e ho rotto il mio server. Poi ho provato con Flash + un file di testo. Mi sono arreso e non ci provo da 10 anni. Ma recentemente ho sentito parlare di webhook e websocket. Ed entrambi sembrano essere un modo per farlo, ma in realtà non capisco bene la differenza. Qualcuno può spiegare?

Webhook

I webhook servono per la comunicazione da server a server. Funzionano da un server che dice a un altro server che vuole che i dati vengano inviati a un certo URL quando succede qualcosa.

Questo articolo parla di alcuni usi dei webhook nei servizi più diffusi. Questa organizzazione parla molto del loro utilizzo nel contesto delle API RESTful.

Websocket

I websocket sono (di solito) per la comunicazione dal server al browser. Il server ospita un server websocket e i client possono aprire una connessione a quel server. Questo è popolare ora soprattutto perché è più veloce e richiede meno risorse rispetto ai vecchi modi di risolvere il problema, come il polling lungo / COMET .

È possibile connettere 2 server utilizzando websocket , ma di solito non è per questo che vengono utilizzati.

La confusione

Anche se uno di questi è (esclusivamente) server-server e uno è (principalmente) browser-server, queste tecnologie sono spesso discusse negli stessi luoghi, quasi come se risolvessero gli stessi problemi. Se guardi la catena abbastanza in alto, vedi che entrambi risolvono il problema della comunicazione "in tempo reale", ma risolvono diversi aspetti di questo problema in modi molto diversi .

Una situazione in cui potrebbe esserci un confronto diretto è se stai creando un'API che verrà utilizzata da un server di terze parti. In questa situazione, potresti fornire un'API webhook o un'API websocket . Entrambi consentono alle terze parti di ottenere rapidamente gli aggiornamenti:

• Se scegli i webhook, quella terza parte dovrà comunque trovare un modo per inviare le modifiche di cui stai parlando ai browser dei loro client.
• Se fornisci un'API websocket, la terza parte può semplicemente configurare il proprio sito in modo che ciascuno dei suoi utenti si connetta direttamente alla tua API websocket e i loro server devono fare meno lavoro.

Di seguito sono riportate alcune informazioni aggiuntive per la scelta tra webhook e websocket.

Le comunicazioni da server a server tramite websocket sono diventate popolari con una nuova generazione di app di chatbot. Ora, molti chatbot eseguiti su websocket forniscono il vantaggio principale di non richiedere un URL pubblico per i bot interni e privati. In questo ambiente, di seguito sono riportate alcune linee guida su quando considerare l'utilizzo di webhook e websocket.

Websocket

• Se la tua app è un'app browser, usa i websocket perché la tua app non può ricevere webhook.
• Se la tua app è un'app server che riceve messaggi da un servizio su Internet e non desideri aprire il firewall, considera i websocket. Alcune aziende richiedono una revisione della sicurezza delle informazioni prima di aprire tali connessioni.

Webhook

• Se la tua app dell'app server deve effettuare molti abbonamenti, preparati a gestire il volume di connessioni websocket aperte al tuo server ( consulta questo articolo per connessioni websocket 1M ) o passa ai webhook. Alcuni chatbot popolari sono passati dai websocket ai webhook per migliorare la scalabilità.
• Se la tua app server viene eseguita come funzione cloud su (AWS Lambda, Google Cloud Functions, ecc.), Utilizza i webhook perché la tua app non manterrà aperta la connessione websocket.
• Se la tua app server è in esecuzione sul livello gratuito Heroku, usa i webhook perché il tuo Dyno andrà in stop e dovrà dormire per 6 ore al giorno, a meno che tu non indichi manualmente al tuo server di dormire.