Estrategias para exponer las API sin afectar al backend

Ya hemos hablado en nuestro blog de cómo las APIs son capaces no sólo de agilizar las integraciones y la arquitectura informática interna, sino también de permitir nuevas estrategias de negocio.

Sin embargo, existe una preocupación recurrente sobre cómo integrar los sistemas heredados con las nuevas tecnologías estratégicas (IoT, AI+Analytics, etc.), sin que ello suponga un impacto masivo en el backend y minimizando los riesgos. Las API pueden ayudar.

¿Cuáles son las mejores estrategias sin impacto en el backend para la exposición de las APIs?

Sabemos que no siempre es posible trabajar en un campo verde, el escenario ideal en el que podemos empezar todo desde cero.

Muchos entornos corporativos tienen sistemas heredados que son cruciales para su actividad, pero que también presentan dificultades en términos de evolución e integración.Los sistemas heredados llevan un cierto estigma de ser monolíticos, problemáticos y difíciles de evolucionar y de tener largos ciclos de entrega y tecnologías zombis (las que ya nadie domina, pero que siguen rodando). Sin embargo, esto no siempre es malo. El sistema puede funcionar de forma estable, satisfactoria y con una baja relación coste/beneficio de las sustituciones.

Aun así, la creciente complejidad y las oportunidades del negocio digital requieren una alta conectividad entre una variedad de sistemas, protocolos y aplicaciones en la nube, así como agilidad en las nuevas implementaciones, con seguridad y compatibilidad.

Entonces, #cómohacerlo? ¡Apis!

Al exponer las API, los sistemas heredados cruciales para su actividad pueden mantenerse e integrarse con sistemas de otras plataformas, de forma segura, con bajo acoplamiento, estandarizada, sencilla e interoperable.Hay algunos enfoques para exponer las API. En primer lugar, debemos hablar del antipatrón, también conocido como "lo que no hay que hacer".

El antipatrón: Estrategia ascendente (¡no lo hagas!)

Es decir, coger una herramienta de mercado que haga alguna conexión con su interfaz o base de datos y exponer las APIs.

¿Por qué no se recomienda?

Este diseño expondrá a los desarrolladores a los problemas presentes en el sistema heredado. La exposición ideal de las APIs requiere que se centren en los desarrolladores que las van a utilizar, que sean sencillas de usar, que sigan buenas prácticas, que respondan a lo que necesitan y que ofrezcan documentación y soporte de fácil acceso.

Estas herramientas pueden incluso proporcionar agilidad a la hora de crear un MVP, pero no recomendamos este enfoque como solución definitiva.

¿Y cuál sería la solución ideal? API-First: Estrategia descendente

En primer lugar, debemos definir cuál será el mejor diseño para las API, teniendo en cuenta que no es sólo para una máquina. Está dirigida a los desarrolladores, por lo que debe ser fácil de entender y utilizar para ellos.

Por ello, proponemos establecer una capa que denominamos API-front, conectada al sistema heredado y compuesta por 2 subcapas:

API Facade: abstrae todo el legado y permite componer, por ejemplo, las API de SaaS con un mainframe, exponiéndolo en un formato adecuado.

Mediar - rutas de la API de la fachada al backend. De esta manera, queremos exponer la API en un formato ideal para los diferentes dispositivos y frontends.

Para el backend heredado, hay 2 líneas de estrategias que se pueden seguir:

• Sin impacto en el código del backend

• Con impacto en el código del backend

Ambos presentan sus ventajas y desventajas, y la elección depende mucho de la arquitectura del legado.

Vamos a discutir las principales estrategias:

Con impacto: Creaciones directas de APIs estandarizadas

Si puede introducir su código heredado y puede exponer APIs estandarizadas (HTTP/REST), hágalo.

Esta es la estrategia con una solución más precisa.

Sin impacto en el código del backend: Acceso a la capa de servicio/API

Ejemplo 1 - Arquitectura web o cliente-servidor

En este tipo de arquitectura, probablemente habrá una forma de conectarse al servidor, a través de algún tipo de protocolo (TCP Socket, Corba, SOAP, etc.).Si tienes una gateway para tu aplicación (la llamamos "API desordenada", es decir, está fuera de un diseño estandarizado), entonces es posible adoptar la estrategia API-First , estableciendo la capa API-front para exponer las APIs con un protocolo estandarizado (básicamente, REST y JSON).

Ejemplo 2 - Arquitectura Mainframe

En esta arquitectura, tienes protocolos de acceso (HPR-IP, TCP-IP, etc.) al mainframe, y el sistema generalmente devuelve una cadena posicional. La capa frontal de la API trabaja sobre esa cadena y la pone en el formato adecuado.

Un punto de atención es la escalabilidad. Puede darse el caso de que el backend o el protocolo no sean escalables. En ese caso, es necesario considerar otras arquitecturas, más modernas y con buena escalabilidad.

Ventajas de utilizar esta estrategia:

• Uso de las funciones empresariales (capa) de la aplicación
• No requiere modificaciones de código en la aplicación
• Transformaciones de protocolo y formato de datos muy pesados

Dificultades que pueden surgir:

• Diversidad de protocolos y sus peculiaridades
• Conocer todos los servicios y funciones disponibles
• Dificultad para lograr la adhesión a RESTful
• Dilemas en escenarios de composición aparente
• Escalabilidad

Sin impacto en el código del backend: Acceso a la capa de datos

Si no hay protocolos de acceso a las aplicaciones, una forma posible es realizar una conexión directa a la base de datos y exponer la API de forma estandarizada.

Ventajas de utilizar esta estrategia:

• No requiere modificaciones de código en la aplicación
• Va directamente al grano

Dificultades que pueden surgir:

• No hay reutilización de las reglas de negocio, excepto si las reglas estaban en Procedimientos Almacenados
• Puede ser necesaria una nueva implementación de algunas reglas de negocio
• API-Front tiende a ser complejo y con poca cohesión

Sin impacto en el código del backend: Web Scrapping o Web Harvesting

Esta estrategia consiste en simular la navegación en la app y tomar los datos de la interfaz web.

Para estos casos, existe el módulo Node.js X-Ray, que permite manipular el DOM de forma dinámica y puede resultar muy útil.

Ventajas de utilizar esta estrategia:

• Uso de las funciones empresariales (capa) de la aplicación
• Uso del propio protocolo HTTP
• No requiere modificaciones de código en la aplicación
• Interesante para un MVP

Dificultades que pueden surgir:

• Dificultad de implementación en HTML/DOM malformado
• Las modificaciones en el HTML/DOM tienden a romper el código de Scraping
• Cuestiones jurídicas relativas a los derechos de autor
• Los datos de la aplicación no se muestran en una Vista.

De nuevo, todas las estrategias tienen sus ventajas y desventajas, y la elección de la mejor opción dependerá mucho de la arquitectura presente en el backend.

¿Quiere saber más sobre cómo crear un frente de API? ¿Cuál es la estrategia más adecuada para su entorno? Tienes más preguntas sobre cómo exponer APIs?* Artículo basado en la conferencia "Exposing legacy and trapped backends APIs", presentada en QCon 2016 por Fábio Rosato, Professional Services Manager en Sensedia.

‍