Envío y recepción de webhooks en AWS: innove con las notificaciones de eventos

Esta publicación fue realizada por Daniel Wirjo, arquitecto de soluciones, y Justin Plock, arquitecto principal de soluciones

Los webhooks, comúnmente conocidos como API inversas o API push, permiten que las aplicaciones se integren entre sí y se comuniquen casi en tiempo real. Permite la integración de eventos empresariales y del sistema.

Ya sea que esté creando una aplicación de software como servicio (SaaS) que se integre con los flujos de trabajo de sus clientes o que reciba notificaciones de transacciones de un proveedor, los webhooks desempeñan un papel fundamental a la hora de impulsar la innovación, mejorar la experiencia del usuario y agilizar las operaciones.

En esta publicación explica cómo crear con webhooks en AWS cubriendo dos escenarios:

• Proveedor de webhooks: Aplicación SaaS que envía webhooks a una API externa.
• Consumidor de Webhooks: Una API que recibe webhooks con capacidad para gestionar grandes cargas útiles o payload.

Esta publicación incluye arquitecturas de referencia de alto nivel con consideraciones, mejores prácticas y ejemplos de código para guiar su implementación.

Envío de webhooks

Para enviar webhooks, debe generar eventos y enviarlos a API de terceros. Estos eventos facilitan las actualizaciones, los flujos de trabajo y las acciones en el sistema de terceros. Por ejemplo, una plataforma de pagos (proveedor) puede enviar notificaciones sobre el estado de los pagos, lo que permite a las tiendas de comercio electrónico (consumidores) enviar productos una vez confirmados.

Arquitectura de referencia de AWS para un proveedor de webhooks

La arquitectura consta de dos servicios:

• Entrega de webhooks: Aplicación que entrega webhooks a un punto de enlace externo especificado por el consumidor.
• Administración de suscripciones: Una API de administración que permite al consumidor administrar su configuración, incluida la especificación de los puntos de enlace de entrega y los eventos que desea suscribir.

Consideraciones y mejores prácticas para enviar webhooks

Al crear una aplicación para enviar webhooks, tenga en cuenta los siguientes factores:

Generación de eventos: Considere cómo genera los eventos. En este ejemplo, se utiliza Amazon DynamoDB como fuente de datos. Los eventos se generan mediante la captura de cambios de datos para DynamoDB Streams y se envían a Amazon EventBridge Pipes. A continuación, simplifique el formato de respuesta de DynamoDB mediante un transformador de entrada.

Con EventBridge, puede enviar eventos prácticamente en tiempo real. Si los eventos no son urgentes, puedes enviar varios eventos en un lote. Esto se puede hacer sondeando nuevos eventos con una frecuencia específica mediante EventBridge Scheduler. Para generar eventos a partir de otras fuentes de datos, considere enfoques similares con las notificaciones de eventos de Amazon Simple Storage Service (S3) o Amazon Kinesis.

Filtrado: EventBridge Pipes admite el filtrado mediante patrones de eventos coincidentes, antes de que el evento se dirija al destino objetivo. Por ejemplo, puede filtrar los eventos relacionados con las operaciones de actualización de estado en la tabla de pagos de DynamoDB hasta el punto de enlace de la API del suscriptor correspondiente.

Entrega: Los destinos de la API de EventBridge entregan eventos fuera de AWS mediante llamadas a la API REST. Para proteger el punto de enlace externo de los picos de tráfico, debe establecer un límite de frecuencia de invocación. Además, los reintentos con un retraso exponencial se gestionan automáticamente dependiendo del error. Una cola de mensajes fallidos de Amazon Simple Queue Service (SQS) conserva los mensajes que no se pueden entregar. Estas pueden proporcionar una entrega escalable y resiliente.

Estructura de carga útil o payload: Considere cómo los consumidores procesan las cargas útiles de los eventos. En este ejemplo, se utiliza un transformador de entrada para crear una carga útil estructurada, alineada con la especificación de CloudEvents. CloudEvents proporciona un formato estándar del sector y una estructura de carga común, con herramientas de desarrollo y SDK para los consumidores.

Tamaño de la carga útil: Para una entrega rápida y confiable, mantenga el tamaño de la carga útil al mínimo. Considere la posibilidad de entregar solo los detalles necesarios, como los identificadores y el estado. Para obtener información adicional, puedes proporcionar a los consumidores una API independiente. A continuación, los consumidores pueden llamar a esta API por separado para obtener la información adicional.

Seguridad y autorización: Para entregar los eventos de forma segura, se establece una conexión mediante un método de autorización como OAuth. Bajo el capó, la conexión almacena las credenciales en AWS Secrets Manager, que las cifra de forma segura.

Administración de suscripciones: Considere cómo los consumidores pueden administrar su suscripción, por ejemplo, especificando los puntos de enlace HTTPS y los tipos de eventos a los que suscribirse. DynamoDB almacena esta configuración. Amazon API Gateway, Amazon Cognito y AWS Lambda proporcionan una API de administración para las operaciones.

Costos: En la práctica, el envío de webhooks conlleva un costo, que puede llegar a ser considerable a medida que se vaya creciendo y se generen más eventos. Considera implementar políticas de uso y cuotas y permitir que los consumidores se suscriban solo a los tipos de eventos que necesiten.

Monetización: Considere facturar a los consumidores en función de su volumen o nivel de uso. Por ejemplo, puede ofrecer un nivel gratuito para facilitar el acceso a los webhooks, pero solo hasta un volumen determinado. Para volumen adicional, puede cobrar una tarifa de uso que se ajusta al valor empresarial que ofrecen sus webhooks. En el caso de grandes volúmenes, puede ofrecer un nivel premium en el que ofrece una infraestructura dedicada a determinados consumidores.

Monitoreo y solución de problemas: Más allá de la arquitectura, considere los procesos para las operaciones diarias. Dado que los puntos de enlace son gestionados por terceros, considere la posibilidad de habilitar el autoservicio. Por ejemplo, permita a los consumidores ver los estados, reproducir eventos y buscar registros de webhooks anteriores para diagnosticar problemas.

Escenarios avanzados: Este ejemplo está diseñado para casos de uso populares. Para escenarios avanzados, considere la posibilidad de utilizar servicios alternativos de integración de aplicaciones, teniendo en cuenta sus cuotas de servicio. Por ejemplo, Amazon Simple Notification Service (SNS), para llegar a un mayor número de consumidores, Lambda para ofrecer flexibilidad a la hora de personalizar las cargas útiles y la autenticación, y AWS Step Functions, para organizar un patrón de disyuntores a fin de desactivar a los suscriptores poco fiables.

Recibir webhooks

Para recibir webhooks, necesita una API para proporcionársela al proveedor de webhooks. Por ejemplo, una tienda de comercio electrónico (consumidor) puede confiar en las notificaciones proporcionadas por su plataforma de pago (proveedor) para asegurarse que los productos se envíen a tiempo. Los webhooks presentan un escenario único, ya que el consumidor debe ser escalable, resiliente y garantizar que se reciban todas las solicitudes.

Arquitectura de referencia de AWS para un consumidor de webhooks

En este escenario, considere un caso de uso avanzado que pueda gestionar grandes cargas útiles mediante el patrón de verificación de notificaciones.

A alto nivel, la arquitectura consiste en:

• API: Un punto de enlace de la API para recibir webhooks. A continuación, un sistema basado en eventos autoriza y procesa los webhooks recibidos.
• Almacén de carga útil: S3 Proporciona almacenamiento escalable para cargas útiles de gran tamaño.
• Procesamiento de webhooks: EventBridge Pipes proporciona una arquitectura extensible para el procesamiento. Puede agrupar en lote, filtrar, enriquecer y enviar eventos a una variedad de servicios de procesamiento como objetivos.

Consideraciones y mejores prácticas para recibir webhooks

Al crear una aplicación para recibir webhooks, tenga en cuenta los siguientes factores:

Escalabilidad: Los proveedores suelen enviar los eventos a medida que se producen. API Gateway proporciona un punto de enlace gestionado y escalable para recibir eventos. Si no está disponible o está limitado, los proveedores pueden volver a intentar la solicitud; sin embargo, esto no está garantizado. Por lo tanto, es importante configurar los límites de consumo y ráfaga adecuados. Limitar las solicitudes en el punto de entrada mitiga el impacto en los servicios descendentes, donde cada servicio tiene sus propias cuotas y límites. En muchos casos, los proveedores también son conscientes del impacto en los sistemas posteriores. Por lo tanto, envían eventos a una velocidad límite, normalmente de hasta 500 transacciones por segundo (TPS).

Además, API Gateway le permite validar las solicitudes, supervisar cualquier error y proteger contra la denegación de servicio distribuida (DDoS). Esto incluye los ataques de capa 7 y capa 3, que son amenazas habituales para los consumidores de webhooks dada su exposición pública.

Autorización y verificación: Los proveedores pueden admitir diferentes métodos de autorización. Considere un escenario común con el código de autenticación de mensajes basado en hash (HMAC), en el que se establece un secreto compartido y se almacena en Secrets Manager. A continuación, una función de Lambda verifica la integridad del mensaje y procesa una firma en el encabezado de la solicitud. Por lo general, la firma contiene un nonce con una marca de tiempo y una fecha de caducidad para mitigar los ataques de repetición, en los que un atacante envía eventos varias veces. Como alternativa, si el proveedor admite OAuth, considere la posibilidad de proteger la API con Amazon Cognito.

Tamaño de la carga útil: los proveedores pueden enviar una variedad de tamaños de carga útil. Los eventos se pueden agrupar en una sola solicitud más grande o pueden contener información importante. Tenga en cuenta los límites de tamaño de la carga útil en su sistema basado en eventos. API Gateway y Lambda tienen límites de 10 Mb y 6 Mb. Sin embargo, DynamoDB y SQS están limitados a 400 KB y 256 KB (con extensión para mensajes de gran tamaño), lo que puede suponer un cuello de botella.

En lugar de procesar toda la carga útil, S3 la almacena. A continuación, se hace referencia a ella en DynamoDB mediante el nombre del bucket y la clave del objeto. Esto se conoce como patrón de verificación de reclamaciones. Con este enfoque, la arquitectura admite cargas útiles de hasta 6 MB, según la cuota de carga útil de invocación de Lambda.

Idempotencia: Por confiabilidad, muchos proveedores priorizan la entrega al menos una vez, incluso si eso significa no garantizar exactamente una entrega única. Pueden transmitir la misma solicitud varias veces, lo que resulta en duplicados. Para solucionar este problema, una función Lambda compara el identificador único del evento con los registros anteriores de DynamoDB. Si aún no se ha procesado, se crea un ítem de DynamoDB.

Ordenamiento: Considere procesar las solicitudes en el orden previsto. Como la mayoría de los proveedores dan prioridad a la entrega al menos una vez, los eventos pueden estar fuera de lugar. Para indicar el orden, los eventos pueden incluir una marca de tiempo o un identificador de secuencia en la carga útil. De lo contrario, es posible que el ordenamiento se haga en lo posible en función del momento en que se reciba el webhook. Para gestionar el orden de forma fiable, selecciona servicios basados en eventos que garanticen la realización de los pedidos. En este ejemplo, se utilizan DynamoDB Streams y EventBridge Pipes.

Procesamiento flexible: EventBridge Pipes proporciona integraciones a una gama de servicios basados en eventos como objetivos. Puede enrutar los eventos a diferentes objetivos en función de los filtros. Los diferentes tipos de eventos pueden requerir procesadores diferentes. Por ejemplo, puede utilizar Step Functions para orquestar flujos de trabajo complejos, Lambda para operaciones informáticas con un tiempo de ejecución inferior a 15 minutos, SQS para almacenar en búfer las solicitudes y Amazon Elastic Container Service (ECS) para tareas de cómputo de larga duración. EventBridge Pipes proporciona transformación para asegurar que solo se envíen las cargas útiles necesarias, y la enriquece si se requiere información adicional.

Costos: Este ejemplo considera un caso de uso que puede gestionar cargas útiles de gran tamaño. Sin embargo, si puede asegurarse de que los proveedores envíen cargas útiles mínimas, considere una arquitectura más simple sin el patrón de verificación de reclamos para minimizar los costos.

Conclusión

Los webhooks son un método popular para que las aplicaciones se comuniquen y para que las empresas colaboren e integren con sus clientes y socios.

En esta publicación, se muestra cómo crear aplicaciones para enviar y recibir webhooks en AWS. Utiliza servicios sin servidor, como EventBridge y Lambda, que son adecuados para casos de uso basados en eventos. Incluye arquitecturas de referencia de alto nivel, consideraciones, prácticas recomendadas y ejemplos de código para ayudarle a crear su solución.

Para conocer los estándares y las mejores prácticas en materia de webhooks, visita los recursos comunitarios de código abierto WebHooks.fyi y CloudEvents.io.

Para obtener más recursos de aprendizaje sin servidor, visita Serverless Land.

Este contenido es una traducción del Blog Original en inglés traducido por Diego Casas y revisado por Christian Bolaños.