Los webhooks son una forma ligera, abierta y eficaz de trabajar con eventos generados por sistemas de terceros con los que desee integrarse.
De hecho, una de las opciones de integración que tiene como desarrollador que se integra en Marketplacer es suscribirse a webhooks y escuchar eventos, incluyendo, pero no limitado a:
- Creación de productos
- Actualizaciones de pedidos
- Notificaciones de envío
Sin embargo, a pesar de los beneficios de usar webhooks para integrar, un inconveniente que encontrarás es su incapacidad para ser enrutados directamente a tu máquina de desarrollo local.
En este artículo analizamos 3 formas que le permiten trabajar dentro de esa (comprensible) limitación.
Una configuración típica de Webhook
Para aclarar un poco más la cuestión, cuando se configura un webhook en un sistema de terceros se suele proporcionar información sobre:
- El "evento" que desea recibir, por ejemplo, nuevo pedido creado
- Los datos que deben enviarse, por ejemplo, Id. de pedido, Dirección de entrega, Importe del pedido, etc.
- A dónde desea que se envíen los datos (el destino del punto final HTTP)
Es en este último punto en el que te puedes quedar un poco descolocado como desarrollador que quieres trabajar con estos eventos en tu máquina local - ¿qué destino configuras para que los eventos se envíen a localhost?
Aunque no existe un estándar para los webhooks, la mayoría de ellos se implementan como peticiones HTTP POST con un cuerpo JSON que se envía al sistema consumidor (en este caso, tu máquina local).
Por ejemplo, si intento configurar un webhook en Marketplacer para enviar eventos de Factura a un endpoint localhost, obtendría la siguiente respuesta:
Y mientras que usted puede conseguir un error ligeramente diferente en otras plataformas, el problema fundamental sigue siendo, la plataforma de terceros no puede enrutar eventos webhook a localhost ...
El resto de este artículo explica cómo trabajar con esta limitación.
1. Fingir
En realidad, esto es un poco trampa, pero puede ser sorprendentemente útil...
Para utilizar este enfoque todo lo que tienes que hacer es utilizar un cliente HTTP API como Postman o Insomnia y simplemente hacer peticiones HTTP POST directas a tu punto final de desarrollo localhost, esencialmente "fingiendo" una petición webhook real. (Clientes como Postman e Insomnia ejecutándose localmente en tu máquina de desarrollo pueden hacer peticiones a destinos localhost).
Para que esta petición "falsa" sea lo más realista posible, tendrás que asegurarte de replicarla lo más cerca posible del webhook original del sistema fuente. Para ello necesitarás:
- Generar una solicitud de webhook real
- Recibir esa solicitud webhook en algún lugar (Por ejemplo, webhook.site)
- Examinar la carga útil del cuerpo y las cabeceras
- Reproduzca ese cuerpo y cabeceras con su cliente HTTP (por ejemplo, Postman)
Aunque este método puede considerarse un poco tramposo, puede resultar realmente útil en las primeras fases de desarrollo, incluso si dispone de otros métodos.
Algunas de las razones son:
- En realidad, no tiene que activar un webhook en el sistema de origen, lo que a veces puede llevar mucho tiempo.
- Puede manipular fácilmente las cabeceras y la carga útil del cuerpo directamente, de nuevo sin tener que generar un evento webhook real...
Aunque esta opción es útil en las fases iniciales (y posiblemente posteriores) del desarrollo, no le proporciona una verdadera experiencia de integración de extremo a extremo. En ese caso, tendrías que considerar una de las otras opciones...
2. Utilizar una aplicación de entrada
El segundo método requiere el uso de una aplicación de entrada o túnel, siendo la más conocida Ngrok.
Ngrok (y aplicaciones similares como Localtunnel), le proporcionan una url enrutable que se asigna a un punto final localhost en su máquina de desarrollo. Esto significa que puedes proporcionar la url enrutable al sistema que genera webhooks (por ejemplo, Marketplacer), y esos webhooks eventualmente llegarán a tu máquina local, y más específicamente a la aplicación que estás construyendo.
Las ventajas de esta solución son:
- Muy fácil de configurar (Ngrok y Localtunnel lo son de todos modos)
- Ngrok ofrece un plan gratuito decente
- Recibe webhooks "reales" en su aplicación
Una de las desventajas potenciales de este enfoque es, por supuesto, las consideraciones de seguridad que puede tener al abrir un túnel desde su máquina local a lo que es esencialmente un punto final público. Dependiendo de la industria en la que trabajes, o de la organización para la que trabajes, usar algo como Ngrok puede que ni siquiera sea una opción disponible para ti dados los recelos sobre las potenciales amenazas de seguridad.
Para obtener una guía más detallada sobre la configuración de Ngrok, consulte nuestro artículo complementario en Medium.
Si los problemas de seguridad que rodean a este método le prohíben emplearlo, hay otro enfoque que puede adoptar...
3. Utilizar un proxy
Hay algunas variaciones de este patrón, pero esencialmente se basa en tener acceso a un punto final enrutable en algún lugar (el "proxy") que recibe (y almacena) el tráfico webhook desde el sistema de origen. A continuación, debe recuperar los mensajes webhook almacenados en su máquina local y, por último, enrutarlos a su aplicación local.
Como puedes imaginar, hay muchas formas de conseguirlo, pero yo utilizo la siguiente arquitectura:
Este enfoque se basa en 3 componentes:
- Una función HTTP de Azure
- Un bus de servicios Azure
- Abonado al bus de servicios
A continuación hablamos un poco más de ellas.
Función HTTP de Azure
Esto actúa como un punto final HTTP enrutable que se puede utilizar para recibir directamente webhooks del sistema de origen, en este caso Marketplacer. Cuando Azure Function recibe un evento webhook, lo coloca inmediatamente en el Service Bus.
Azure Service Bus
Azure Service Bus actúa como ambos:
- El almacén persistente (o semipersistente) para los mensajes webhook
- El método de entrega de esos mensajes a un abonado (local)
En relación con la persistencia de los mensajes, el Bus de Servicio la proporciona pero sólo durante un periodo de tiempo relativamente corto (por defecto es de 14 días).
Abonado al bus de servicios
Puede ser cualquier aplicación que pueda suscribirse a nuestro Azure Service Bus y leer sus mensajes. En este caso concreto, se trata de una aplicación de consola .NET que se activa cada vez que se coloca un mensaje en el tema correspondiente del bus de servicios. Este agente reenvía estos mensajes a cualquier endpoint localhost configurado.
Este enfoque puede parecer como utilizar un mazo para romper una nuez, pero funciona y tiene las siguientes ventajas:
- Corresponde más a algo que es probable ver en un entorno de producción empresarial.
- El uso de un bus de servicios conlleva todas sus ventajas inherentes, entre las que se incluyen: seguridad, enrutamiento, persistencia de mensajes y entrega basada en eventos.
Las desventajas de este enfoque son:
- Complejidad. Hay varias partes móviles, lo que hace que todo sea más difícil de configurar, supervisar y detectar fallos que con algo como Ngrok.
- Coste. Aunque el coste real de esta solución con unos pocos cientos o incluso miles de webhooks sería mínimo, sigue teniendo un coste potencial asociado.
En conclusión
0Las 3 opciones son viables para ponerte en marcha con el desarrollo local de webhooks, y como la mayoría de las cosas en la vida, elegirás la que se adapte a tus propias necesidades. Sin embargo, por su simplicidad y eficacia, la opción de entrada es difícil de superar en un contexto de desarrollo local.
