Header Ads Widget

Ticker

6/recent/ticker-posts

WebHooks vs WebSub: ¿Cuál es mejor para la transmisión de eventos en tiempo real?


 Streaming y tiempo real son la nueva moda. Los desarrolladores quieren que sus aplicaciones brinden una experiencia interactiva; esto implica no solo recibir datos en tiempo real, sino también poder transmitir eventos. Pero para alguien que busca primero en WebHooks y WebSub , la falta de documentación sobre terminologías puede resultar confusa. Así que comencemos desde el principio.

Transmisión de eventos: ¿para qué sirve?

Cuando se habla de transmisión, probablemente esté pensando en transmisión de datos y menos a menudo en transmisión de eventos . Las dos nociones son muy diferentes debido a que utilizan tecnologías diferentes.

Cuando hablamos de la transmisión de eventos, no estamos realmente interesados ​​en los datos que se encuentran debajo.
Lo que realmente importa es que ha sucedido algo, algo que implica una reacción tuya o algo de lo que quieres que se notifique a tus usuarios.

WebHooks

A veces llamado Devolución de llamada HTTP definida por el usuario o Devolución de llamada HTTP posterior definida por el usuario , WebHook es un concepto . Nada mas. No encontrará verdaderas especificaciones o bibliotecas de WebHook; depende de usted implementarlo de la manera que desee.

¿Como funciona?

Como cliente, registrarse en un WebHook es tan simple como registrar una URL de devolución de llamada en el sitio web del proveedor. Y luego, cada vez que ocurre un nuevo evento en el servidor, puede enviar una solicitud a su URL de devolución de llamada para notificarle sobre la actualización. Sencillo, ¿no?

¡En efecto! Entonces, ¿qué necesito para empezar?

Para un consumidor, su única tarea es definir una URL de devolución de llamada . Pero tenga en cuenta que esta URL debe ser accesible desde el exterior, por lo que no hay host local ni firewall.

Como proveedor de WebHook, tiene dos tareas en su lista de verificación:

  • Definir un punto final de suscripción
  • Implementa tu cola de WebHook

Y, por supuesto, una vez completada esta lista de verificación, ¡no olvide crear una interfaz agradable en su sitio web si desea que los usuarios puedan suscribirse a su WebHook!

Relacionado: 5 protocolos para arquitecturas de API basadas en eventos

Definir un punto final de suscripción

Puede declarar solo un punto final para aceptar nuevas solicitudes de suscripción enviadas en una POST /WebHookllamada, pero podría ser bueno tener algo un poco más desarrollado.

Por ejemplo, puede exponer algunos otros recursos útiles como:

  • GET /WebHook para enumerar WebHooks existentes
  • GET /WebHook/{id} para recuperar detalles de un WebHook existente
  • PUT /WebHook/{id} para actualizar un WebHook existente
  • DELETE /WebHook/{id} para darse de baja de un WebHook existente

Pero como dije anteriormente, no hay ninguna especificación, por lo que todo lo anterior es opcional.

Implementa tu cola de WebHook

Este es el momento en el que las cosas se vuelven un poco complicadas. Tenemos 4 soluciones diferentes aquí:

  • Solicitudes HTTP en línea : cada vez que se activa un evento, verá las suscripciones existentes para este evento, recorrerá cada una de ellas, enviará POSTsolicitudes y luego realizará cualquier limpieza, falla o reintento lógico que pueda ser necesario. Funcionará, pero no lo recomendaría a menos que esté absolutamente seguro de que tendrá una pequeña cantidad de eventos y suscripciones. E incluso en ese caso, tenga en cuenta que todas esas acciones retrasarán su respuesta.
  • Crear una cola de base de datos : con esta opción, creará un registro en su base de datos existente para cada notificación que necesite enviar. Luego, necesitará un proceso separado para buscar con frecuencia nuevas notificaciones y enviarlas. No se escala bien, pero es una solución si no puede agregar otra pieza de tecnología a su pila.
  • Use una cola adecuada : si sabe que necesitará escalar su solución, probablemente sea mejor usar un agente de mensajes adecuado como RabbitMQ , ActiveMQ o Redis . Aún necesitará tener un proceso separado para consumir elementos de la cola y enviar notificaciones, pero de esta manera, ahorrará recursos de bases de datos.
  • Lote : si sabe que su API enviará una gran cantidad de enlaces al mismo tiempo, probablemente sea mejor que los agrupe en un solo enlace . Por ejemplo, Facebook agrega los cambios y los envía por lotes como máximo una vez cada 5 segundos, o cuando el número de cambios no enviados supera los 1000.
Lea también: Detenga el sondeo y considere los ganchos REST

Ok, todo está arreglado. ¿Qué podría salir mal?

Es posible que aparezcan algunos errores en su camino hacia eventos en tiempo real. En primer lugar, ataque DDos .

Si el WebHook al que se ha suscrito genera más solicitudes de las que su aplicación puede manejar, el resultado será un ataque DDos. Entonces, en primer lugar, intente evaluar la escala esperada del WebHook al que se ha suscrito y asegúrese de que su aplicación pueda mitigar el tráfico .

Dado que está exponiendo una URL pública para recibir notificaciones, una aplicación maliciosa podría acceder a ella que le enviará datos falsos o intentará hacer un DDOSing de su aplicación, esta vez por motivos dañinos. Esa es la razón por la que generalmente se recomienda tener A) una URL de devolución de llamada por registro y B) que sea menos legible por humanos.

Las notificaciones perdidas son otro posible problema. El trabajo de un WebHook es entregar datos, no necesariamente prestar atención a lo que está haciendo con ellos. Si, por alguna razón, su aplicación tiene un error y el WebHook al que se ha suscrito no presta atención a su respuesta, puede perder datos.

Por el contrario, si verifica su respuesta y hace varios intentos cuando no está proporcionando el que espera, terminó con notificaciones duplicadas. Facebook, por ejemplo, volverá a intentarlo inmediatamente y luego unas cuantas veces más con una frecuencia decreciente durante las próximas 24 horas. Después de ese tiempo, se descartarán las actualizaciones que no se hayan entregado.

WebSub

Anteriormente llamado PubSubHubbub, PubSub, o empujar, WebSub es un protocolo abierto, basado en la publicación / suscripción de patrones y en WebHooks. Inicialmente diseñado para extender los protocolos Atom y RSS para las fuentes de datos, se puede aplicar a cualquier tipo de datos siempre que sea accesible a través de HTTP. Desde abril de 2017, WebSub ha sido adoptado por el W3C como recomendación candidata.

The Pub, The Sub y The Hub.

WebSub se basa en un ecosistema de Publishers (Medium, WordPress, etc.), Hubs (Superfeedr, Switchboard, etc.) y Suscriptores (Feedly, Flipboard, etc.).

En comparación con WebHook, WebSub requiere mucho menos esfuerzo para los editores, ya que todo lo que necesitan hacer es declarar el Hub que están usando con el encabezado del enlace y luego hacer ping cuando tienen nuevo contenido publicado.

Para los suscriptores, no hay una gran diferencia, ya que todavía van a hacer una solicitud de suscripción, pero esta vez al Hub, que les hará ping a su vez cuando se publique contenido nuevo.

En este punto, podría preguntarse ...

¿Eso es todo? Un nuevo jugador en el medio pero todo sigue igual. ¡¿Cuál es el punto de?!

… ¡Y tendrías razón! Pero la cosa es que este jugador en particular va a cambiar algunas reglas.

Verificación de intención

Una gran diferencia entre WebHook y WebSub es la verificación de la intención . Queremos estar seguros de que el usuario ha solicitado suscribirse al contenido. Y de la misma manera, si deciden darse de baja, queremos estar seguros de que nadie lo ha hecho en su nombre.

Para hacerlo, el Hub simplemente pedirá confirmación para ambas acciones. Concretamente, una vez recibida la solicitud de suscripción, el Hub enviará una GETsolicitud en la URL de devolución de llamada del usuario con un hub.challengeparámetro. Este parámetro es solo una cadena aleatoria, pero debe enviarse de regreso al Hub (¡y solo a él!) Como el cuerpo de la respuesta. Del mismo modo, se aplica el mismo mecanismo para la cancelación de la suscripción.

Ping ligero

La segunda gran diferencia con WebHooks es que, de forma predeterminada, las notificaciones de contenido nuevo son un ping ligero . Básicamente, en lugar de enviar todo el contenido, el Hub solo enviará a los suscriptores nuevas entradas en el feed con partes de encabezado (título, enlaces, etc.). Depende de ellos buscarlo ... o no.

Esto hace una gran diferencia porque sabemos que no se leerá todo el contenido, entonces, ¿por qué enviarlos a todos los suscriptores, cada vez? ¿Por qué no ahorrar recursos dejando que los suscriptores los obtengan solo si así lo desean?

Sin embargo, si no se ajusta a sus necesidades, dependiendo del Hub que esté utilizando, puede decidir enviar un ping gordo . Pero tenga cuidado, podría ser una opción de pago.

¿Y qué pasa con los problemas de WebHook? ¿Está todo arreglado?

Si el paso de verificación de la intención le impide ataques DDos intencionales y notificaciones falsas, aún se deben considerar otros escollos.

Entonces, ¿cuándo debo optar por uno u otro?

Los WebHooks son absolutamente perfectos cuando desea crear flujos de trabajo que reaccionen inmediatamente a un evento (ejemplo: dispositivos médicos conectados). Por otro lado, WebSub es el que debe optar si desea proporcionar eventos junto con una mayor cantidad de datos (ejemplo: una nueva publicación de una publicación de blog es un evento interesante, pero también le interesan los datos que hay detrás) .

Conclusión

Eso es todo para el panorama general. Este post no tiene la pretensión de ser exhaustivo sino mucho más de ser una introducción a ambas soluciones. Si desea ir más allá, los siguientes recursos pueden ser útiles:

WebHook :

  • WebHooks.org : si la Wiki no se ha actualizado durante un tiempo, permanece casi actualizada y la lista de correo sigue activa.
  • ¿Qué es un WebHook? De Nick Quinlan

WebSub :

  • Repositorio PubSubHubbub : contiene ejemplos en varios idiomas.
  • ¿Cómo implementar PubSubHubbub? por Julien Genestoux

Publicar un comentario

0 Comentarios