Antes de comenzar definamos que es un patrón arquitectónico y en qué se diferencian con un patrón de diseño.
Ambos son soluciones probadas y efectivas para problemas recurrentes en el diseño y desarrollo de software, pero tienen diferentes alcances y enfoques.
Los patrones arquitectónicos son estrategias de alto nivel para diseñar la estructura general de un sistema de software. Se centran en la organización de los componentes, las relaciones y las interacciones entre ellos mientras que los patrones de diseño son soluciones detalladas y específicas para problemas más pequeños y específicos dentro de un sistema, estos se centran en el diseño y la implementación de clases, objetos y relaciones dentro de un componente o módulo particular.
Ahora veamos una introducción de un API Gateway.
Un API Gateway no es más que un componente de software que actúa como intermediario entre aplicaciones o clientes que consumen servicios y múltiples microservicios o APIs subyacentes. Su función principal es proporcionar un punto de entrada único para las solicitudes de API.
Una introducción de los beneficios que nos puede aportar esta definición hasta el momento serían los siguientes:
- Permitir reemplazar los servicios sin la necesidad de actualizar al cliente, dado que es el API-GATEWAY que tiene el acoplamiento.
- Podemos verlo como una aplicación a nivel de arquitectura del patrón de diseño delegate.
- El cliente no conoce la ubicación de cada uno de los servicios, tales como localización de las direcciones IP, cantidad de instancias que existan. El cliente solo tiene acoplamiento hacia un punto y es este punto quien tiene el acoplamiento a los diferentes servicios.
Ahora, ¿sabías que el api gateway puede trabajar con diferentes patrones arquitectónicos?, conozcamolos:
Gateway Routing Pattern
Este patrón se refiere al uso de un componente de gateway para enrutar las solicitudes de los clientes a los servicios apropiados en función de criterios de enrutamiento predefinidos. El gateway actúa como un punto de entrada único para los clientes y se encarga de recibir las solicitudes de los clientes, evaluar los criterios de enrutamiento (como la URL, el tipo de solicitud, la versión de la API, etc.) y enrutar la solicitud al servicio apropiado en función de los criterios. Este patrón es útil cuando se necesita controlar y gestionar la ruta de las solicitudes de los clientes a diferentes servicios, y permite una mayor flexibilidad y escalabilidad en el enrutamiento de solicitudes.
Principales beneficios:
- Centralización del Enrutamiento: Con un único punto de entrada (el gateway), se simplifica la gestión y configuración del enrutamiento de solicitudes hacia los diferentes servicios. Esto facilita la adaptación y el ajuste de las rutas sin tener que modificar directamente cada microservicio.
- Flexibilidad en la Dirección del Tráfico: El patrón de enrutamiento con puerta de enlace permite cambiar las reglas de enrutamiento y las asociaciones entre rutas y servicios de manera más sencilla. Esto es especialmente útil cuando se necesita ajustar el tráfico en función de condiciones cambiantes, como la carga de los servicios o la disponibilidad de recursos.
- Aislamiento de Microservicios: Los clientes no necesitan conocer la estructura interna de los microservicios ni interactuar directamente con ellos. Esto permite que los microservicios se mantengan independientes y facilita cambios en su implementación sin afectar a los clientes.
- Similitud con patrones de diseño de software: Es la aplicación del patrón delegate a nivel de arquitectura de software.
Gateway Aggregation Pattern
Este patrón se refiere a la consolidación y agregación de múltiples solicitudes de clientes en una sola solicitud que se envía a varios servicios en el backend. El gateway actúa como un punto de entrada único para los clientes y se encarga de recibir las solicitudes de los clientes, combinarlas y enrutarlas a los servicios apropiados en función de las necesidades del cliente. Luego, el gateway recopila las respuestas de los servicios y las combina en una sola respuesta que se envía al cliente. Este patrón es útil cuando se necesita reducir la latencia y el ancho de banda de la red, ya que evita que los clientes realicen múltiples solicitudes a diferentes servicios por separado.
Principales beneficios:
- Simplificación de la Interfaz del Cliente: Los clientes solo necesitan conectarse a un único Gateway para acceder a datos de diferentes servicios y fuentes. Esto simplifica la interacción del cliente y evita la necesidad de que los clientes conozcan la estructura interna de los microservicios.
- Centralización de la Lógica de Agregación: La lógica de combinación y agregación de datos se encuentra en el Gateway, lo que significa que los clientes no necesitan preocuparse por realizar múltiples llamadas a diferentes servicios. El Gateway se encarga de obtener y combinar los datos de manera eficiente.
- Reutilización de Datos: Al combinar datos de diferentes fuentes en una sola interfaz, se puede promover la reutilización de información en diferentes partes de la aplicación.
- Similitud con patrones de diseño de software: Es la aplicación del patrón Facade a nivel de arquitectura de software.
Los dos patrones vistos hasta ahora no son excluyentes, es decir, tu puedes tener un gateway que aplica Gateway Aggregation Pattern y Gateway Routing Pattern de tal forma que algunos endpoints son simplemente para hacer un ruteo hasta un servicio y otros que son un endpoint que consolida diferentes llamados
Anti-corruption Layer pattern
Este es un patrón arquitectónico que se utiliza para proteger y aislar un sistema nuevo o actualizado de componentes externos o legados que operan con un modelo de datos o un diseño diferente. Se aplica cuando hay una necesidad de comunicación entre sistemas que tienen estructuras de datos incompatibles o paradigmas de diseño divergentes.
Implementa una capa de adaptador entre nuestro sistema con un subsistema externo que no comparten la misma semántica. Esta capa traduce las solicitudes que hace un subsistema al otro subsistema.
Con este patrón es importante ver donde se ubica la capa anti corruption dado que si busca interpretar y traducir las respuestas de otro sistema, debe estar en el sistema de origen.
Principales beneficios:
- Independencia y Aislamiento: Los sistemas heredados o externos pueden tener estructuras de datos, reglas de negocio y modelos de diseño únicos que no encajan bien con el nuevo sistema. Aplicando la Capa Anti-Corruption, puedes aislar la complejidad y las peculiaridades de estos sistemas, permitiendo que el nuevo sistema mantenga su propio diseño coherente y adaptado.
- Estandarización de Interfaces: Al trabajar con sistemas externos que tienen interfaces propias poco convencionales o poco amigables, la Capa Anti-Corruption te permite definir interfaces más limpias y coherentes que reflejen las necesidades y el diseño de tu nuevo sistema.
- Separación de Responsabilidades: La Capa Anti-Corruption puede convertirse en el lugar centralizado donde se gestionan todas las interacciones con sistemas externos, separando así esta preocupación de los componentes principales del nuevo sistema.
- Similitud con patrones de diseño de software: Es la aplicación del patrón Adapter a nivel de arquitectura de software.
¿Es posible aplicar con los otros patrones arquitectónicos?, la respuesta corta es SÍ, sí es posible combinarlos y ofrecer los tres patrones en un mismo componente.
Ubicación del Gateway en nuestras arquitecturas
Tenemos dos ubicaciones donde es posible ubicar nuestro componente gateway:
- Dentro de nuestro sistema para reducir el acoplamiento hacia otro subsistema:
Este gateway puede trabajar como Gateway Aggregation Pattern y Gateway Routing Pattern y anti-corruption layer pero solo es válido para componentes del contexto del sistema A - Al aplicar un gateway en un subsistema estamos buscamos ofrecer reutilización, al igual que reducir el acoplamiento en los sistemas A y B.
Este gateway puede trabajar como Gateway Aggregation Pattern y Gateway Routing Pattern, pero no como anti-corruption layer.
BFF
Un BFF no es más que la aplicación de todos los patrones vistos hasta ahora (Gateway Aggregation Pattern, Gateway Routing Pattern, anti-corruption layer) pero con un contexto limitado de uso hacia un único cliente.
Se usa principalmente para respaldar la solicitud del cliente con un único Backend.
El propósito de tener un BFF es brindarle a su cliente una interfaz enfocada para conectarse.
Diferencia entre un BFF y un API Gateway
Un API gateway puede ser usado por más de un cliente, un BFF provee servicios a un único cliente.
El BFF es el responsable de completar las transacciones que necesita el cliente para funcionar, de tal forma que si nuestro Front necesita de múltiples API para obtener la información que necesita, el BFF trabaja como Gateway Aggregation Pattern para consolidar la información en un único llamado.
Un API sería un componente (posiblemente REST) encargado de proveer una funcionalidad del negocio dentro del dominio que se encuentre.
Conclusiones:
- Utiliza un BFF cuando tu front deba comunicarse con diferentes API, si tu front solo tiene comunicación con un API, un BFF es sobrediseño.
- Ubica el API-Gateway dependiendo de lo que busques, ya sea tener características de aggregate, routing o anti-corruption layer.
- Existen más patrones arquitectonicos que se pueden aplicar en los Gateway.
- Un Gateway es para proveer a 1 o más clientes, un BFF siempre será para un único cliente.
- Si necesitas solo el patrón Gateway Routing y estas trabajando en ambiente cloud, lo mejor es adpotar uno de los servicios de aws o gcp