.png){kind=small}
.png){kind=small}
Publicado originalmente en NordicAPIs
Los desafíos impuestos por cualquier negocio digital generalmente se concentran en la agilidad y escalabilidad. Aun así, hoy en día, las arquitecturas de software tradicionales no soportan el volumen de datos y estándares de integración necesarios para permitir un negocio competitivo. Implementar soluciones alternativas para suministrar activos digitales de forma segura y escalonable es la clave para el éxito de la jornada digital de una empresa.
Existen varias maneras de definir qué es una API. Resumiendo, APIs son interfaces técnicas que permiten la construcción de ecosistemas integrados. Al desarrollar productos digitales y apalancar su conectividad por medio de APIs, es posible conectarse a una variedad de asociados, entregar servicios para desarrolladores de aplicaciones y permitir la reutilización de servicios internos, entre otros beneficios .REST es el estilo más común utilizado por expositores de API. No obstante, surgieron nuevas alternativas como GraphQL o gRPC . Dependiendo del caso de uso (integración interna entre microservicios o flexibilidad para que los desarrolladores escojan cuáles datos desean en la respuesta), estos nuevos estilos pueden traerles más beneficios a una estrategia de integración.
Un evento es cualquier acción que provoca un cambio sistémico de estado. En otras palabras, un evento es una actualización en una aplicación que genera valor para alguien (por medio de otra aplicación).Para contextualizar, considere los eventos en un sistema de pago con tarjeta de crédito. Cada vez que un usuario intenta un pago con su tarjeta de crédito, una notificación es generada para informar o solicitar la confirmación. Observe que no toda acción o actualización ejecutada en una aplicación es considerada un evento. En vez de esto, los eventos deben siempre estar vinculados a un valor comercial significativo.En una integración basada en eventos (también conocida como Event-Driven Architecture (EDA), los consumidores se inscriben en eventos y reciben notificaciones de ellos. Esto se opone al modelo de integración definido por APIs tradicionales, donde los consumidores hacen solicitudes de pool para obtener las informaciones que ellos necesitan. Tres elementos principales componen un EDA:
Existen dos topologías principales para implementar una arquitectura orientada a eventos, usando un mediador o corredor:
Un mediador es considerado en escenarios donde hay requisitos para manipular u orquestar el evento.
Los productores de eventos publican eventos en una fila para ser consumidos por el Mediador. Esto puede ser notificado sobre el nuevo evento o leer la fila de forma proactiva. Enseguida, el Mediador hará la orquestación del evento, enviándolo en el orden correcto para los diferentes Procesadores, y también enriqueciendo el evento con contenido proveniente de servicios anteriores, si es necesario. Por ejemplo, en un proceso de generación de pedido, un servicio responsable de la gestión de inventarios tiene interés en recibir notificaciones cuando productos fueren adicionados a un carrito de compras, para informar su disponibilidad. Y el servicio de facturación necesitará saber si hay productos disponibles para generar la factura del pedido.
En las situaciones en que no hay requisitos de orquestación, la recomendación es la adopción de Broker.
Semejante a la Mediación, el evento será compartido con la Corredora (a través de encuesta o push, dependiendo de la decisión de arquitectura tomada). La principal diferencia es que el evento será enviado a todos los Event Processors interesados en este evento. Siguiendo nuestro ejemplo anterior, el carrito de compras, después de la generación de un nuevo pedido, el servicio de gestión de pedidos enviaría una notificación de evento para la fila de servicio de gestión de inventario. Si hubiere productos disponibles, este servicio puede enviar una nueva notificación de evento para la fila de servicio de facturación para generar una factura.Decidir entre mediador o corredor es una decisión arquitectónica que dependerá de los requisitos y problemas de negocios que usted está intentando resolver.
A pesar de que ambos modelos parezcan oponerse, ellos son, en realidad, complementarios uno al otro. En un escenario híbrido, las APIs aprovechan las interacciones online donde las aplicaciones exigen feedback instantáneo para las acciones realizadas, mientras los eventos aprovechan las comunicaciones asíncronas. Ambas tecnologías combinadas pueden ser muy poderosas. Esta combinación puede permitir que las empresas permitan que clientes o asociados obtengan lo mejor de la palabra síncrona de dos maneras: primero, al hacer llamadas de API para crear pedidos o iniciar pagos y, segundo, al recuperar actualizaciones de rastreo después de recibir una notificación de evento.Existen implementaciones de arquitecturas orientadas a eventos que suministran no solamente la notificación en si, sino también el contenido actualizado. Pero incluso en este enfoque, una API podría ser accionada internamente para recuperar las actualizaciones a ser entregadas a los suscriptores del Evento.
No es difícil pensar en escenarios combinando APIs y eventos. Podemos ver el mundo del Open Banking , un campo en expansión para APIs, para obtener algunos insights excelentes.Los bancos desempeñan un papel crucial en Open Banking, una vez que posee la mayoría de los datos de los clientes. Los terceros proveedores (TPPs), por otro lado, están interesados en los datos del cliente para potenciar varios casos de uso. Estas áreas incluyen la opción de hipoteca más accesible, el mejor proveedor de seguros o incluso la agregación de cuentas, que coloca todos los detalles de ahorro y cuenta corriente de diferentes bancos en una única exhibición.La manera como los TPPs recuperan datos del banco es por medio de llamadas de API. Pero ¿una solución debe iniciar una nueva llamada de API cada vez que alguien abre una aplicación para verificar la integridad de sus cuentas? ¡La respuesta es no!Usando eventos, los TPPs pueden ser notificados solamente cuando algo cambie. Accionar una API para actualizar las informaciones solamente cuando sea necesario evita llamadas perdidas. Este es un ejemplo simple donde APIs y eventos pueden ser combinados para entregar valor real a todo el ecosistema.
Una estrategia de integración basada en recursos síncronos y asíncronos puede ser muy benéfica para consumidores y proveedores de API. Los consumidores no deben construir su integración con base en solicitudes de pooling constantes enviadas a los proveedores. Ellos pueden ofrecer un modelo de integración que reduce la carga en sus servidores y dirige importantes momentos de negocios.Antes de decidir el modelo de integración, es muy importante identificar a sus clientes y asociados-objetivo, así como la mejor forma de integración con ellos para suministrar sus servicios. Solamente después de la conclusión de este análisis, puede ser definido el modelo de integración más adecuado.
Hey, click and join the Sensedia News!
