différences entre webhook et websocket

J’ai toujours voulu faire un chat en temps réel.

J’ai fait cela il y a des années dans PHP + Ajax + Mysql et j’ai cassé mon serveur. Puis j’ai 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 de webhooks et de websockets. Et les deux semblent être un moyen de le faire, mais je ne comprends pas vraiment la différence. Tout le monde peut expliquer?

Webhooks

Les Webhooks sont destinés à la communication entre serveurs. Ils fonctionnent par un serveur qui dit à un autre serveur qu’il veut que les données soient envoyées à une certaine URL lorsque quelque chose se produit.

Cet article parle de certaines utilisations de webhooks dans les services populaires. Cette organisation parle beaucoup de leur utilisation dans le contexte des API RESTful.

Websockets

Les Websockets sont (généralement) pour la communication de serveur à 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 coûteux en ressources que les méthodes plus anciennes de résolution du problème, comme l’ interrogation longue / COMET .

Il est possible de connecter 2 serveurs à l’aide de Websockets , mais ce n’est généralement pas ce à quoi ils sont utilisés.

La confusion

Même si l’un d’entre eux est (exclusivement) serveur-serveur et l’autre (principalement) serveur-navigateur, 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 suffisamment haut, vous constatez qu’ils résolvent tous deux le problème de la communication “en temps réel”, mais ils résolvent différents aspects de ce problème de manières très différentes .

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 ce cas, vous pouvez fournir une API Webhook ou une API Websocket . Les deux permettent au tiers d’obtenir rapidement des mises à jour:

  • Si vous choisissez les Webhooks, ce tiers devra toujours trouver un moyen de transférer les modifications que vous leur dites vers les navigateurs de leurs clients.
  • Si vous fournissez une API websocket, la tierce partie peut simplement configurer son site afin que chacun de ses utilisateurs se connecte directement à votre API websocket, et que ses serveurs doivent travailler moins.

Voici quelques informations supplémentaires pour choisir entre les webhooks et les websockets.

Les communications de serveur à serveur sur Websockets sont devenues populaires avec une nouvelle génération d’applications de chatbot. Maintenant, de nombreux chatbots exécutés sur des websockets offrent un avantage majeur de ne pas nécessiter d’URL publique pour les robots internes. Dans cet environnement, vous trouverez ci-dessous des instructions sur l’utilisation de Webhooks par rapport aux Websockets.

Websockets

  • Si votre application est une application de navigateur, utilisez 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, envisagez les Websockets. Certaines entresockets exigent un examen de la sécurité des informations avant d’ouvrir de telles connexions.

Webhooks

  • Si votre application serveur doit faire de nombreux abonnements, soyez prêt à gérer le volume de connexions Websocket ouvertes à votre serveur ( voir cet article pour les connexions WebMix 1M ) ou passez à Webhooks. Certains chatbots populaires sont passés des websockets aux webhooks pour améliorer leur évolutivité.
  • Si votre application serveur s’exécute en tant que fonction cloud sur (AWS Lambda, Fonctions Google Cloud, etc.), utilisez les Webhooks car votre application ne conservera pas la connexion Websocket ouverte.
  • Si votre application serveur s’exécute sur le niveau gratuit Heroku, utilisez les Webhooks car votre Dyno s’endort et doit dormir 6 heures par jour, à moins que vous ne demandiez manuellement à votre serveur de dormir.