différences entre webhook et websocket
J'ai toujours voulu faire un chat en temps réel.
Je l'ai fait il y a des années en PHP + Ajax + Mysql et j'ai cassé mon serveur. J'ai ensuite essayé avec Flash + un fichier texte. J'ai abandonné et je n'ai pas essayé depuis 10 ans. Mais récemment, j'ai entendu parler des webhooks et des websockets. Et ils semblent tous les deux être un moyen de le faire, mais je ne comprends pas vraiment la différence. N'importe qui peut expliquer?
Webhooks
Webhooks sont pour la communication de serveur à serveur. Ils fonctionnent par un serveur indiquant à un autre serveur qu'il veut que les données soient envoyées à une certaine URL quand quelque chose se produit.
Cet article parle de certaines utilisations des webhooks dans les services populaires. Cette organisation parle beaucoup de leur utilisation dans le contexte des API RESTful.
Websockets
Websockets sont (généralement) pour la communication du serveur au navigateur. Le serveur héberge un serveur WebSocket et les clients peuvent ouvrir une connexion à ce serveur. Ceci est populaire maintenant principalement parce qu'il est plus rapide et moins gourmand en ressources que les anciennes méthodes de résolution du problème, comme longue interrogation / COMÈTE .
C'est possible de connecter 2 serveurs à l'aide de websockets , mais ce n'est généralement pas ce pour quoi ils sont utilisés.
La confusion
Même si l'un d'eux est (exclusivement) serveur-serveur et l'autre (principalement) navigateur-serveur, ces technologies sont souvent discutées aux mêmes endroits, presque comme si elles résolvaient les mêmes problèmes. Si vous regardez la chaîne assez haut, vous voyez qu'ils résolvent tous les deux le problème de la communication "en temps réel", mais ils résolvent différents aspects de ce problème de manière très différente.
Une situation où il peut y avoir une comparaison directe est si vous créez une API qui sera consommée par un serveur tiers. Dans cette situation, vous pouvez fournir une API webhook ou une API websocket. Les deux permettent au tiers d'obtenir rapidement des mises à jour:
- Si vous choisissez des webhooks, ce tiers devra toujours trouver un moyen de transmettre les modifications que vous leur signalez aux navigateurs de leur client.
- Si vous fournissez une API websocket, le tiers peut simplement configurer son site pour que chacun de ses utilisateurs se connecte directement à votre API websocket, et leurs serveurs doivent faire moins de travail.
Voici quelques informations supplémentaires pour choisir entre les webhooks et les websockets.
Les communications de serveur à serveur via les sockets Web sont devenues populaires avec une nouvelle génération d'applications de chatbot. Maintenant, de nombreux chatbots s'exécutent sur des websockets avec l'avantage principal de ne pas nécessiter d'URL publique pour les bots internes et privés. Dans cet environnement, voici quelques conseils sur le moment d’envisager l’utilisation de webhooks et de websockets.
Websockets
- Si votre application est une application de navigateur, utilisez des websockets car votre application ne peut pas recevoir de webhooks.
- Si votre application est une application serveur recevant des messages d'un service sur Internet et que vous ne souhaitez pas ouvrir votre pare-feu, pensez aux prises Web. Certaines entreprises exigent un examen de la sécurité des informations avant d'ouvrir de telles connexions.
Webhooks
- Si votre application serveur doit effectuer de nombreux abonnements, préparez-vous à gérer le volume de connexions Websocket ouvertes à votre serveur ( voir cet article pour les connexions WebMocket 1M ), ou passez à des webhooks. Certains chatbots populaires sont passés des websockets aux webhooks pour améliorer l'évolutivité.
- Si votre application serveur s'exécute en tant que fonction cloud sur (AWS Lambda, Google Cloud Functions, etc.), utilisez des webhooks car votre application ne gardera pas la connexion websocket ouverte.
- Si votre application serveur s'exécute sur le niveau gratuit Heroku, utilisez les webhooks car votre Dyno se mettra en veille et devra dormir 6 heures par jour, sauf si vous demandez manuellement à votre serveur de dormir.