DEV Community: Miguel Ángel Sánchez Chordi

API Gateway vs Load Balancer vs Reverse Proxy

Miguel Ángel Sánchez Chordi — Wed, 03 Apr 2024 07:02:13 +0000

Infraestructuras de Gestión y Distribución de Tráfico

Conoce las diferencias entre las distintas infraestructuras de gestión y distribución de tráfico

Este post se publicó originalmente en el blog Secture&Code

Escalado de aplicaciones web

Con el paso del tiempo, las aplicaciones basadas en la web y los servicios que ofrecen han ido incrementado tanto en escala como en complejidad. Aunque era lo habitual años atrás, la idea de mantener un proyecto grande funcionando con un solo servidor es algo cada vez menos realista.

Para manejar mayores volúmenes de tráfico tenemos dos formas diferentes de escalado: el escalado vertical y el escalado horizontal.

Escalado vertical

Básicamente consiste en mejorar el hardware sobre el que corre nuestro proyecto, añadiendo más memoria, más CPU, más disco duro, más tarjetas de red… Antiguamente era la forma más barata de escalar y a día de hoy es una opción poco realista, ya que a medida que la demanda del servicio web aumenta, puede llegar un punto en el que el escalado vertical ya no sea suficiente para satisfacer las necesidades de rendimiento y disponibilidad del proyecto.

Escalado horizontal

Consiste en agregar más servidores o instancias de manera distribuida para manejar la carga. Esto permite una mayor flexibilidad y capacidad para adaptarse a cambios en la demanda, así como una mayor tolerancia a fallos, ya que los servidores individuales pueden fallar sin degradar significativamente la disponibilidad del servicio.

Infraestructuras de Gestión y Distribución de Tráfico

Es aquí, en las estrategias de escalado horizontal, donde juegan un papel importante las infraestructuras de gestión y distribución de tráfico, ya que gracias a ellas podemos controlar el flujo de datos y distribuir la carga de manera eficiente entre múltiples servidores o instancias, garantizando así un rendimiento óptimo y una alta disponibilidad del servicio.

Vamos a ver tres de las más conocidas: Reverse Proxy (Proxy inverso), API Gateway (Puerta de acceso) y Load Balancer (balanceador de carga).

Si no te has visto en la necesidad de utilizarlas, es posible que tengas dudas sobre qué hace cada una de ellas o en qué se diferencian, así que vamos a ver las características y usos de cada una de ellas.

Reverse Proxy

La función principal del reverse proxy es enmascarar la dirección real de un servidor

Empezamos por el más simple de los tres, el reverse proxy o proxy inverso.

El reverse proxy básicamente es un servidor que actúa como intermediario entre los clientes y el o los servidores de destino. En lugar de establecerse una comunicación directa en cliente y servidor, el cliente conecta con el reverse proxy y este se encarga de pasar la petición al servidor y devolver la respuesta correspondiente a los clientes.

Con qué propósito usamos un reverse proxy?

Seguridad. Actúa como una barrera entre los clientes y los servidores de destino, ocultando la estructura interna de la red y proporcionando una capa adicional de seguridad contra ataques maliciosos.
Cacheo de contenido estático. Almacena en caché el contenido estático como imágenes, archivos CSS y JavaScript para reducir la carga en los servidores de origen y mejorar los tiempos de carga de la página.
Terminación SSL/TLS. Gestiona las conexiones SSL/TLS de los clientes y las termina en el proxy antes de reenviar las solicitudes a los servidores de destino, lo que simplifica la gestión de certificados SSL/TLS y mejora el rendimiento de los servidores. De esta forma la conexión HTTPS es únicamente entre el cliente y el proxy. Esto es especialmente útil cuando el reverse proxy enmascara más de un servidor.
Balanceo de carga. Sí, así es, el reverse proxy se puede usar como balanceador de carga, ya que distribuye el tráfico entrante entre varios servidores de destino para mejorar la escalabilidad y la disponibilidad del servicio.

La función de proxy inverso la realizan la mayoría de servidores web comerciales, como NGINX, Apache y Microsoft IIS, y también software específico como HAProxy.

Load Balancer

Un balanceador de carga reparte el tráfico entre distintas instancias o servidores de un mismo servicio

Un balanceador de carga (o Load Balancer en inglés) es un dispositivo o software que distribuye el tráfico de red entrante entre múltiples servidores, con el objetivo de mejorar el rendimiento, la disponibilidad y la fiabilidad de una aplicación o servicio web.

Al igual que en el caso del reverse proxy, actúa como un intermediario entre el cliente y (en este caso) los servidores, ya que no es solo uno sino varios los servidores que oculta el load balancer. Al ser varios servidores, se paralelizan las peticiones y se puede manejar un flujo de peticiones mucho mayor

Con qué propósito usamos un balanceador de carga_?_

Distribución de carga. Distribuye el tráfico de red entre varios servidores para evitar la sobrecarga de uno solo y garantizar un uso equitativo de los recursos disponibles.
Mejora del rendimiento. Al distribuir la carga de trabajo entre múltiples servidores, un balanceador de carga puede mejorar el tiempo de respuesta y el rendimiento general de una aplicación o servicio.
Alta disponibilidad. Si un servidor falla, el balanceador de carga puede redirigir automáticamente el tráfico a servidores alternativos que estén funcionando correctamente, lo que garantiza la disponibilidad continua del servicio.
Escalabilidad. Facilita la adición o eliminación dinámica de servidores según las necesidades de carga, lo que permite escalar horizontalmente la infraestructura de manera flexible.

Cómo reparte la carga un balanceador?

Dependiendo de su implementación, puede utilizar algoritmos de balanceo de carga simples, como round-robin (cada solicitud se envía a los servidores en secuencia) o algoritmos más avanzados que consideran la carga actual de los servidores, la latencia, entre otros factores.

Los algoritmos de distribución de carga más habituales incluyen:

Round Robin. Este algoritmo distribuye las solicitudes de manera uniforme entre los servidores en secuencia. Cada solicitud se envía al siguiente servidor en la lista, y cuando se alcanza el último servidor, se vuelve al principio.
Least Connections (Menos Conexiones). Este algoritmo dirige las nuevas solicitudes al servidor con la menor cantidad de conexiones activas en ese momento. Es útil para distribuir la carga de manera más equitativa, considerando la carga real de cada servidor.
Least Response Time (Menor Tiempo de Respuesta). Similar al algoritmo de Menos Conexiones, este enfoque dirige las solicitudes al servidor que tiene el menor tiempo de respuesta en ese momento. Ayuda a maximizar la capacidad de respuesta y el rendimiento general del sistema.
IP Hashing (Hashing de IP). Este algoritmo utiliza la dirección IP del cliente para determinar a qué servidor enviar la solicitud. De esta manera, todas las solicitudes de un cliente particular se envían siempre al mismo servidor, lo que puede ser útil para mantener la sesión de un usuario en un servidor específico.
Weighted Round Robin (Round Robin Ponderado). Este algoritmo asigna un peso a cada servidor en función de su capacidad de procesamiento, y luego distribuye las solicitudes en función de esos pesos. Los servidores con mayor capacidad recibirán una mayor proporción de solicitudes.
Random (Aleatorio). Este algoritmo elige aleatoriamente un servidor para manejar cada solicitud entrante. Aunque simple, puede no ser la opción más eficiente en términos de distribución de carga equitativa.

Cómo manejamos las sesiones con un balanceador de carga?

Si el servicio que estamos enmascarando con nuestro balanceador requiere de una sesión, corremos el peligro de que en las siguientes peticiones un mismo cliente sea redirigido a otro servidor que no tenga su sesión guardada, y esto puede producir cierto malestar en el usuario al estar constantemente pidiéndole iniciar sesión de nuevo.

Para ello, los balanceadores de carga cuentan con una característica conocida como sticky bit , que permite que las solicitudes de un cliente se dirijan siempre al mismo servidor durante la duración de una sesión específica, es decir, garantiza la persistencia de sesión al asociar un cliente con un servidor particular.

Cuando se habilita el sticky bit, el balanceador de carga utiliza una técnica, como el hashing de la dirección IP del cliente o la inserción de una cookie en el navegador del cliente, para identificar y asociar al cliente con un servidor específico. Como resultado, todas las solicitudes posteriores de ese cliente durante la misma sesión se redirigen al mismo servidor, lo que asegura una experiencia coherente para el usuario y permite que las sesiones persistan correctamente a través de múltiples solicitudes.

Podemos encontrar implementaciones de balanceadores de carga en las principales plataformas cloud, como AWS Elastic Load Balancer (ELB), Microsoft Azure Load Balancer y Cloud Load Balancing de Google.

API Gateway

Un API Gateway sirve como punto de entrada único a una serie de servicios distribuidos e independientes

Por último, un API Gateway es un componente de software que actúa como punto de entrada único (single entry point) para una variedad de servicios y APIs dentro de una arquitectura de microservicios o de servicios distribuidos. Funciona como una capa intermedia entre clientes y múltiples servicios, proporcionando una interfaz unificada y facilitando la gestión, seguridad, supervisión y orquestación de las solicitudes y respuestas entre ellos.

Cómo funciona un API Gateway?

El funcionamiento de un API Gateway ya es algo más complejo que los casos anteriores. De base podemos entender sus similitudes con el balanceador de carga, pero con un matiz muy importante: tras un API Gateway hay distintos servicio y que además pueden funcionar con diferentes protocolos. De hecho, un API Gateway puede estar encubriendo un servicio que usa internamente un balanceador de carga para repartir la carga del servicio entre distintas instancias o servidores (hablamos por supuesto de magnitudes de tráfico enormes).

Veamos los pasos básicos de su funcionamiento:

Recepción de solicitudes. El API Gateway recibe las solicitudes de los clientes y las enruta a los servicios correspondientes basándose en reglas de enrutamiento configuradas.
Traducción de protocolos. Puede traducir los protocolos de comunicación, por ejemplo, convirtiendo solicitudes HTTP en llamadas a servicios internos usando protocolos como gRPC o Thrift.
Autenticación y autorización. Gestiona la autenticación y la autorización de los clientes, verificando las credenciales y aplicando políticas de acceso antes de enviar las solicitudes a los servicios subyacentes.
Agregación de datos. Puede combinar múltiples llamadas a servicios internos para formar una única respuesta para el cliente, reduciendo así la latencia y el tráfico de red.
Monitorización y análisis. Recopila métricas y registros de las solicitudes y respuestas para facilitar la supervisión, el análisis de rendimiento y la solución de problemas.

Con qué propósito usamos un balanceador de carga?

Unificación de interfaces. Proporciona una única interfaz para los clientes, simplificando su interacción con un conjunto diverso de servicios internos.
Gestión de versiones. Permite la introducción y el control de versiones de APIs, lo que facilita la evolución de los servicios subyacentes sin afectar a los clientes.
Seguridad centralizada. Implementa políticas de seguridad centralizadas, como autenticación, autorización y cifrado, para todos los servicios internos.
Orquestación y transformación. Permite la orquestación de solicitudes a través de múltiples servicios internos y la transformación de datos según sea necesario.
Escalabilidad y disponibilidad. Puede distribuir la carga de manera equitativa entre múltiples instancias de servicios internos, mejorando así la escalabilidad y la disponibilidad del sistema.

Problemas comunes

Una infraestructura tan compleja no está exenta de problemas, veamos cuales son los más comunes:

Cuellos de botella de rendimiento. Un API Gateway puede convertirse en un cuello de botella si no se dimensiona adecuadamente para manejar la carga de solicitudes entrantes.
Complejidad de configuración. Configurar y mantener reglas de enrutamiento, políticas de seguridad y transformaciones de datos puede volverse complejo a medida que aumenta la cantidad de servicios y funcionalidades implementadas.
Puntos únicos de fallo. Si un API Gateway es el único punto de entrada para todos los servicios, un fallo en él puede afectar la disponibilidad de todo el sistema.
Sobrecarga de red : El enrutamiento de todas las solicitudes a través del API Gateway puede introducir una sobrecarga adicional en la red, especialmente en entornos distribuidos a gran escala.

De nuevo, podemos encontrar implementaciones de API Gateway en los principales proveedores de cloud como AWS API Gateway, Azure API Management o Google Cloud API Gateway (Apigee), así como soluciones Open Source como Kong.

Conclusiones

Como hemos podido ver, aunque similares en su propósito, estas tres infraestructuras de gestión y distribución de tráfico tienen usos muy distintos y trabajan de formas muy diferentes.

Es importante saber elegir en cada caso cuál necesitamos, ya que elegir mal puede derivar en añadir un extra de complejidad a nuestro proyecto, además de salirnos caro el error (económicamente hablando).

Recordad, empezad siempre por lo mínimo necesario, siempre habrá tiempo de escalar más alto!

Vertical Slices 101

Miguel Ángel Sánchez Chordi — Sun, 25 Feb 2024 10:02:08 +0000

Clean Architectures

Todo lo que necesitas saber sobre Vertical Slices

Vertical Slices sobre el modelo tradicional de capas

Artículo publicado originalmente en blog Secture&Code

¿De dónde viene el patrón Vertical Slices?

Tras haber hablado durante un tiempo de distintos modelos de Clean Architectures, me gustaría introducir un patrón que discute su eficacia, o al menos sus ventajas a corto/medio plazo.

El patrón Vertical Slices fue creado por Jimmy Bogard como una respuesta a las ya tradicionales arquitecturas limpias (Hexagonal o Ports&Adapters, Onion, Screaming…)

Clean Architecture (siempre según Jimmy), te obliga a seguir una serie de reglas de dependencia que implican crear muchas abstracciones a cambio de muy poco beneficio, ya que el principal objetivo de Clean Architecture es eliminar la dependencia de cualquier framework o librería de terceros.

El beneficio real de estas abstracciones y reglas es difícilmente apreciable, ya que nunca se ha dado el caso de tener que cambiar de Framework o de base de datos (excepto quizá al ejecutar baterías de tests). Pero seguir reglas por seguirlas no va con Jimmy (ni con nadie, supongo), así que propuso su propio modelo de arquitectura.

¿Qué es el patrón Vertical Slices?

Con un patrón de Clean Architecture hacemos una separación por capas, habitualmente Infrastructure (adaptadores de librerías de terceros), Application (lógica de negocio) y Domain (abstracciones y contratos).

La propuesta de Jimmy pasa por, en lugar de dividir nuestro código en capas por cuestiones técnicas, dividirlo por funcionalidad. Cada funcionalidad será una slice y agrupará todas estas capas. De este modo, cada funcionalidad es una caso de uso distinto con distintas necesidades que se abordarán de la forma mas adecuada.

Podría entenderse como un modulo independiente dentro del proyecto, que controla desde la request hasta la response de forma independiente (esto, inevitablemente nos lleva a pensar en CQRS).

Esquema original de Vertical Slices Architecture. Créditos a Jimmy Bogard

La esencia de Vertical Slices Architecture radica en minimizar el acoplamiento entre slices, maximizando a su vez el acoplamiento en cada slice (ejes de cambio).

When adding or changing a feature in an application, I’m typically touching many different “layers” in an application. I’m changing the user interface, adding fields to models, modifying validation, and so on. Instead of coupling across a layer, we couple vertically along a slice. Minimize coupling between slices, and maximize coupling in a slice.

Con este enfoque las capas compartidas desaparecen y las abstracciones se vuelven innecesarias, cada slice implemente únicamente aquello que necesita, y cada slice decide cómo manejar la request que tiene asignada.

Créditos a Jimmy Bogard

Los Domain Logic Patterns de Martin Fowler ya no son una decisión que abarque todo el proyecto, sino que cada slice se autogestiona y decide cuales usar y cuando hacerlo. Esto favorece empezar cualquier slice de la forma más sencilla posible e ir refactorizando a patrones a medida que sea necesario, a su debido tiempo.

Desventajas

El propio Jimmy Reconoce que este patrón no es para todos los equipos, ya que estos deben de tener cierta madureza y experiencia en detectar code smells y en aplicar refactors siguiendo las clásicas técnicas del libro Refactoring to Patterns de Joshua Kerievsky, moviendo lógica compleja a una capa de dominio compartido (siempre y cuando sea realmente necesario)

Conclusión

Leer sobre un patrón que contradice una tendencia al alza como las Clean Architectures siempre resulta sumamente interesante, ya que podemos reflexionar sobre lo que estamos haciendo y por qué lo estamos haciendo (seguimos reglas por seguirlas?).

No obstante, en mi opinión este patrón favorece la falta de coherencia entre las distintas funcionalidades de un proyecto, haciendo que tengas que aprender de nuevo en cada una que vayas a tocar cómo está diseñada o implementada.

Puede que sea un enfoque idóneo en proyectos muy grandes con equipos claramente definidos y con formas de trabajar o necesidades claramente distintas, algo así como aplicar microservicios a nivel monolítico, pero creo que en proyectos más pequeños o con una rotación frecuente entre quién va a trabajar en qué funcionalidad, contribuye más al caos.

Si que me parece un ejercicio interesante desde el punto de vista de que, al pasar por distintas funcionalidades con distintas implementaciones, podemos detectar qué patrones o técnicas están siendo provechosas en otras slices y ver de incorporarlas a otras, eliminando así los patrones implementados solo porque han sido útiles en otra parte de la aplicación. No obstante, me parece un proceso largo que puede tener sentido trabajando en empresas de producto, pero poco favorable cuando trabajamos en proyectos más cortos.

Referencias

Presentación de Vertical Slices Architecture (Jimmy Bogard)
Conferencia de Vertical Slices Architecture(Jimmy Bogard)
Artículo original de Vertical Slices Architecture (Jimmy Bogard)

¿Cómo trabajar correctamente con fechas?

Miguel Ángel Sánchez Chordi — Wed, 14 Feb 2024 07:03:16 +0000

Aprende a manejar fechas en proyectos internacionales

Mapa de zonas horarias del mundo. Créditos: Wikipedia.

Artículo originalmente publicado en Secture&Code

Las fechas son una de las grandes olvidadas en los planteamientos iniciales de un proyecto y esto puede tener repercusión en el mantenimiento a medio largo/plazo. Inicialmente, cuando arrancamos un proyecto simplemente guardamos la fecha y la hora sin preocuparnos demasiado al respecto, pero luego proyecto crece, requiere una adaptación para el mercado internacional (internacionalización) y centramos todo el foco en las traducción y la localización de nuestro sitio web.

Pero, ¿acaso es la misma hora en todos los países? ¿Acaso en España no cambiamos la hora dos veces al año?

Aunque parezca poco importante, puede provocar auténticos desastres administrativos a nuestro proyecto, como, por ejemplo, publicar un producto en otro país 6h antes de lo esperado, o que tareas programadas se ejecuten una hora antes o después de lo necesario debido al cambio de hora.

¿Cómo manejamos todo esto?

Zonas Horarias

En realidad el sistema horario internacional es algo que todos conocemos y que todos los lenguajes de programación de alto nivel que implementan fechas tienen incorporado a su API, por lo que abordar este problema solo requiere de un poco de planificación, consenso y disciplina.

Cuando generamos una fecha con nuestro lenguaje preferido, este, generalmente, lo hará utilizando la zona horaria configurada. Esta configuración puede tener distintos orígenes y prioridades. Veamos algunos ejemplos ordenados de más prioritarios a menos prioritarios:

Configuración en runtime (en tiempo de ejecución): acabamos de configurar el lenguaje para que use una zona por defecto
Configuración del framework o librería de fechas : a lgunos frameworks te permiten ajustar este parámetro para que en todo el proyecto se use la misma configuración (a no ser que se sobreescriba en runtime).
Archivos de configuración : los lenguajes interpretados suelen dejarnos ajustar algunos parámetros del intérprete en archivos del sistema.
Configuración del sistema operativo : s i ninguna de las anteriores ha sido configurada, por defecto usará la del sistema.

⚠ ️ Pro Tip: atención con la configuración de la zona horaria de la base de datos, ya que si permitimos que el motor de la base de datos asigne fechas automáticamente, este lo hará siguiendo su propia configuración, que no tiene por qué ser la misma que la del lenguaje o _runtime._

Coordinated Universal Time (UTC)

Hay una zona horaria especial que nos permite controlar a la perfección estas diferencias entre las distintas zonas horarias, y es la zona UTC (Coordinated Universal Time). Esta zona es la “zona cero”, es decir, no tiene desplazamiento horario, podríamos llamarlo la hora central del planeta. En otros contextos se le conoce como GMT (Greenwich Median Time), aunque UTC es el reemplazo oficial de GMT. En argot militar también se le conoce como Hora Zulú, y permite coordinar operaciones usando una hora común.

Si guardamos todas nuestras fechas en zona UTC, podremos calcular muy sencillamente la fecha en cualquier zona del mundo. De hecho, ni siquiera tendremos que hacer los cálculos, ya que es una función muy común en cualquier librería de fechas o incluso en las APIs propias de los lenguajes de programación. Veamos un ejemplo en PHP:

En este caso he optado por configurar la zona por defecto en runtime, solo para ejemplificar su uso.

Lo interesante de este uso es que el frontend puede determinar la zona horaria del usuario por distintos métodos (dominio, IP, selección manual del usuario…) y mostrar las fechas que vienen del backend ajustadas a la zona horaria del usuario, sin errores, sin problemas derivados por el horario de verano… etc. Y, simultáneamente, el tiempo de todas nuestras operaciones queda coordinado por una hora única en el backend.

Formatos de fecha

El cómo queramos mostrar la fecha a los usuarios ya es un asunto más personal o cultural, en base a los diferente países a los que vayamos a mostrar las fechas. Vamos a ver algunos de los ejemplos más recurrentes:

Formato francés

Es el más extendido en Europa, consiste en una ordenación de día, mes y año, en ese orden. Por ejemplo:

13/12/1989
13-12-1989

Da igual el uso de barras, guiones… lo importante es el orden. En caso de mostrar la hora, esta se muestra a continuación separada por un espacio en blanco, con la ordenación hora, minutos, segundos:

13/12/1989 11:24:26

Formato americano

Es el más extendido en America. Consiste en una ordenación de mes, día y año, en ese orden. Por ejemplo:

12/13/1989
12–13–1989

13/12/1989 11:24:26

Estándar ISO-8601

Se sigue el criterio de especificar en orden primeramente los períodos de tiempo más largos y posteriormente los más cortos. Así, para especificar una fecha primero se escribe el año, posteriormente el mes y a continuación el día.

Por ejemplo, para especificar la fecha 13 de diciembre de 1989 del ejemplo anterior, el resultado sería:

1989–12–13

En el caso de incluir la hora también esta estaría acotada por las letras “T” y “Z”, por ejemplo, si la hora fuesen las 11:26:24am, usaríamos la notación:

1989–12–13T11:26:24Z

Este formato es especialmente útil para realizar ordenaciones eficientes y para comunicar fechas entre distintos sistemas, ya que es un estándar bien conocido y cualquier lenguaje implementa el soporte para esta notación.

Conclusiones

Es conveniente que adoptemos esta práctica de forma habitual, ya que cuando un proyecto escala a nivel internacional, es más difícil realizar la adaptación, ya que tendremos millones de registros en base de datos con la zona horaria equivocada, y cientos de lineas de código que cambiar debido a que no tienen en cuenta la zona horaria.

Puede parecer más cómodo empezar sin tenerlo en cuenta, ya que la fecha que le pasemos al frontend es la que tiene que mostrar, sin conversiones ni nada que impida avanzar de forma rápida y sin engorros, pero como se suele decir: es pan para hoy y hambre para mañana.

Añadir esta práctica va a aportar mucho control a nuestras operaciones coordinadas y al crecimiento a medio/largo plazo de nuestro proyecto.

Bibliografía

Screaming Architecture

Miguel Ángel Sánchez Chordi — Thu, 01 Feb 2024 08:00:27 +0000

Clean Architectures

Arquitecturas que gritan su propósito

Este artículo se publicó originalmente en el blog Secture&Code

Introducción

Cuántas veces has abierto un proyecto y has pensado: Laravel, Symfony, Django, Rails, NestJS, Wordpress…? Y por contra, cuántas veces has abierto un proyecto y has pensado: aplicación de podcast, sistema de venta de tickets, plataforma de alquileres, red social…?

Es bastante común en nuestro mundillo dejarnos llevar por las decisiones que han tomado otros, y por otros me refiero a a los desarrolladores del framework de turno que estemos usando. Arrancamos un proyecto con un framework y directamente nos dejamos llevar por la estructura de directorios y decisiones de arquitectura que más le convenían al equipo que ha desarrollado el framework, en lugar de centrarnos en qué necesita nuestro proyecto para gritar su propósito.

Screaming Architectures

En 2011, Bob Martin proponía el concepto de screaming architecture: arquitecturas que gritan a los cuatro vientos su propósito, el proyecto que modelan, vaya.

El símil más sencillo de entender es el de los planos de un arquitecto: de un solo vistazo se entiende si el diseño corresponde a una casa, un aeropuerto, una plaza, un centro comercial, etc. En ningún momento se habla de materiales. No aún, esos detalles vendrán después. La meta es definir un diseño que cumpla con la especificación del proyecto: un hogar acogedor, un aeropuerto eficiente, una plaza con sombras y bancos, un centro comercial accesible a todo el mundo…

En el campo del desarrollo una buen arquitectura debería de cumplir esos mismos objetivos, ajustarse al sistema que se está modelando, sin importar si la base de datos es MySQL o MongoDB, si usaremos Laravel o Symfony, si usaremos ORMs basados en DataMapper o en ActiveRecord. Nuestra arquitectura debe de poder probarse (testarse) sin haber tomado aún esas decisiones.

El framework solo es una herramienta más

A lo que nos lleva esto es a que debemos considerar el framework que hayamos elegido como una dependencia externa más, no la base sobre la que asentar nuestro dominio. No debemos de tomar las decisiones cruciales en base a las características o funcionalidades que tiene el framework que hayamos elegido, ya que estaremos atándonos a él.

Puede ser tentador, y a todos nos ha pasado, pero ciertamente hay un mundo de ventajas cuando asumimos el control de nuestro dominio, y nos protege contra contratiempos inesperados: dependencias de terceros que se abandonan o que no se actualizan, giros en el diseño que nos afectan de tal manera que no podemos seguir trabajando a no ser que invirtamos tiempo en actualizar al nuevo diseño… etc

Pero no todo es proponerse desacoplarse del framework de turno, tenemos que saber elegir bien nuestras herramientas, ya que muchos frameworks solo funcionan bien si sigues sus reglas y te acoplas a él, y ahí ya depende de nosotros saber si conviene meterse en ese berenjenal, o simplemente dejarse llevar, bien por la duración del proyecto, por las expectativas de crecimiento o simplemente porque es un MVP que desecharemos nada más validemos nuestro negocio.

Si optas por desacoplarte, infórmate bien de tus opciones. Los frameworks que se definen a si mismos como opinionated suelen marcar un modo de trabajo rígido del que es difícil escapar si queremos seguir sacándole partido, y muchas veces es mejor optar por microframeworks que podamos ir ampliando con otras librerías de terceros o con las nuestras propias.

Una buena forma de detectar si será complicado o no desacoplarse del framework, es detectar cuál es su componente principal. Si es un ORM, seguramente sea difícil abstraerse de él, ya que por diseño nos obliga a usar una base de datos, pero si su componente principal es un container de dependencias, ten por seguro que será sencillo, ya que te está dando la herramienta principal para conseguir ese desacople.

Conclusiones

S_creaming architecture_ es más un concepto que una arquitectura en si misma. La única regla que debe de cumplir es gritar su propósito, no ceder el control a un framework, CMS o a una librería que acapare el protagonismo y empuje abajo nuestro dominio de negocio.

No es una tarea sencilla. No siempre va a ser factible. No siempre va a ser rentable. ¿Es una mala idea? En absoluto. En mi experiencia tras haber podido trabajar en proyectos usando este enfoque, he visto que los tiempos de onboarding y adaptación de nuevos desarrolladores es mucho menor, en comparación.

A veces surgen fricciones cuando un desarrollador del framework elegido se une al proyecto y las cosas no se hacen como él acostumbra a hacer, pero su comprensión del dominio es mucho mayor en menos tiempo, y aprender un nuevo workflow es algo que hacemos cada poco tiempo.

Por otra parte, ese control sobre el workflow nos da un extra de independencia a la hora de tomar decisiones relevantes en el diseño de nuestro proyecto y la posibilidad de modificarlo según nuestras necesidades.

En cambio, si el proyecto que afrontas tiene una duración finita, sin posibilidad de expandirse o de crecer, o de añadir más desarrolladores, no dudes en usar las herramientas que consideres para entregar a tiempo, acoplándote y sacándoles todo su jugo

Clean Architectures 101

Miguel Ángel Sánchez Chordi — Thu, 30 Nov 2023 14:23:07 +0000

Arquitecturas Limpias

Todo lo que necesitas saber sobre arquitecturas limpias

Esquema de arquitectura limpia

Post publicado originalmente en el blog Secture&Code

Allá por el año 2012, Bob Martin acuñó el término de “Arquitectura Limpia” para referirse a aquellas arquitecturas de software que cumplen estos requisitos:

Son independientes del framework La arquitectura no necesita que exista un framework por debajo para funcionar, nuestro código debería de poder portarse a otro framework y seguir funcionando. No quiere decir esto que nuestro código de infraestructura no requiera cambios.
Son testables Las reglas de negocio de nuestro código deberían de ser testables (unitariamente al menos) sin depender de servidores web, bases de datos, interfaz de usuario o cualquier librería de terceros.
Son independientes de la capa de presentación (UI) La capa de presentación o frontend debería de ser independiente del sistema, reemplazable y multimedia, es decir, debería de poder ser un entorno web, un entorno de consola, una app móvil, otra API o cualquier otro sistema que podamos imaginar.
Son independientes de la base de datos (DB) Deberíamos de poder cambiar de MySQL a PostgreSQL, MongoDB o cualquier otro provider sin que esto afecte a nuestras reglas de negocio. No quiere decir esto que nuestro código de infraestructura no requiera cambios.
Son independientes de cualquier dependencia externa (third parties) Todo es reemplazable, ninguna dependencia debería de ser fuerte. ¿No nos convence nuestra librería de UUIDs? Reemplazarla debería de ser trivial. ¿Cambiamos de ORM? La lógica de negocio no debería de notarlo.

La regla de dependencia

Veamos una versión simplificada del esquema de arriba:

Esquema de arquitectura limpia simplificado

Cada uno de los círculos concéntricos representa una capa, y esta capa a su vez es una barrera que sólo puede ser atravesada por sus capas superiores. De este modo:

Infraestructura puede acceder a Aplicación y a Dominio
Aplicación puede acceder a Dominio
Dominio sólo puede acceder a Dominio

Cuanto más hacia dentro penetramos en las capas, más nos adentramos en la lógica de negocio, las reglas y las políticas. Cuanto más hacia fuera nos movemos, más cerca estamos de los agentes externos o mecanismos (clientes web o mobile, servicios externos o APIs, servicios de infraestructura como bases de datos, sistemas de colas, etc).

Contenido de las capas

Cada una de estas capas contiene distintos elementos de nuestro código, vamos a hacer un pequeño repaso al contenido de cada una de ellas:

Dominio

Esta es la capa más cercana al negocio, por no decir que es el negocio en sí misma. En la capa de dominio es donde residen todas las piezas fundamentales que, además, servirán como lenguaje común para comunicarse entre las otras capas. Por ejemplo:

Entidades: modelos de datos con identidad propia, compuestos por Value Objects, que pueden ser anémicos o no.
Value Objects: piezas fundamentales para modelar entidades o agregados. Los value objects representan elementos básicos de nuestro dominio, como pueden ser el id de un usuario, su nombre, su correo… estas diminutas clases contienen la lógica de validación de sus valores, no tienen entidad propia y se comparan por valor, como una primitiva más.
Servicios: son pequeñas clases que ejecutan una acción, como puede ser recuperar un usuario de la base de datos, construir la entidad y devolverla o devolver un NullObject si no existe. Estos servicios se pueden usar solos o combinados en los distintos casos de uso.
Eventos: los eventos de dominio son la forma más eficaz de comunicarse en dirección contraria a la de la regla de dependencia. Si una acción de dominio requiere disparar otro caso de uso de la capa de aplicación, será como reacción a un evento.
Excepciones: clases que representan errores comunes que se producen en nuestra aplicación. “Usuario no encontrado”, “Dinero insuficiente”, “El valor no puede ser negativo…”, etc.
Contratos: por contratos, claro está, nos referimos a interfaces como pueden ser UserRepository, LogReporter, ExceptionTracker… etc. Es decir, contratos que se deberán de implementar en la capa de infraestructura. Por ejemplo: UserRepositoryMySQL, SumoLogicLogReporter o SentryExceptionTracker. Estos contratos son los que nos permitirán implementar inversión de dependencias y nos darán la capacidad de cambiar estas dependencias, facilitando por ejemplo la transición de MySQL a MongoDB, ya que la interfaz (contrato) será la misma (UserRepository), pero la implementación no (UserRepositoryMySQL → UserRepositoryMongo).

Aplicación

En esta capa residirán los casos de uso, es decir, los orquestadores que, haciendo uso de elementos de dominio como entidades, excepciones, servicios, value objects… los combinan para obtener una respuesta.

Aquí se pueden aplicar patrones como CQS y CQRS o simplemente casos de uso más simples.

Infraestructura

Aquí tenemos implementaciones de los distintos contratos que ha definido dominio. Esta es la capa que más puede variar su código a la hora de portar nuestro proyecto de un framework a otro o al cambiar de provider de base de datos o al cambiar una librería third party por otra.

Ejemplo de un flujo de aplicación

Veamos un ejemplo del flow de un endpoint:

Flujo de aplicación con la correspondencia de cada capa

En esta imagen podemos apreciar algunos de los componentes que intervienen en la ejecución de un endpoint, y he asociado cada color al de la capa que pertenece.

Controlador: aquí puede haber discrepancias y, en muchos casos, hay quien considera los controladores como parte de la capa de aplicación. Teóricamente es correcto, pero en la práctica nos encontramos con muchos frameworks que impiden que el controlador sea un elemento desacoplado, ya que tiene que heredar de ciertas clases para poder funcionar correctamente, así que en este ejemplo el controlador formará parte de la capa de infraestructura y lo consideraremos parte del framework. Su misión en este caso es simplemente extraer los datos de la request, encapsular los datos en un DTO y pasárselo al caso de uso para que lo maneje. Una vez reciba la respuesta, se encargará de elegir la presentación adecuada y devolver la respuesta.
Caso de uso: esta es la parte de nuestro código que coordina la ejecución de la lógica de negocio. Puede incluir validaciones de los datos de entrada y la coordinación de distintos servicios de dominio para obtener la respuesta deseada, así como lanzar excepciones si se produce un error (esperado o inesperado).
Servicio. Aquí es donde vive la lógica de nuestra aplicación, donde se ejecutan las políticas que hemos definido y donde reside todo el conocimiento. Como se puede apreciar, los servicios de dominio pueden requerir del uso de elementos de infraestructura, pero nunca de forma directa, ya que hacemos uso de la inversión de dependencias para lograrlo.

Implementaciones conocidas de Clean Architecture

Ahora que ya sabes un poco más sobre arquitecturas limpias puede que te pique la curiosidad y quieras implementarla en tus proyectos. ¿Por dónde deberías empezar?

Antes de nada lo más recomendable es que conozcas y domines algunas de las implementaciones más conocidas, así puedes decantarte por cuál se ajusta más a tu estilo, a tu lenguaje o a tu forma de pensar. Algunas de las implementaciones más conocidas son:

Hexagonal Architecture. De Alistair Cockburn.
Onion Architecture. De Jeffrey Palermo.
Screaming Architecture. De Bob Martin.
DCI. De James Coplien.
BCE. De Ivar Jacobson.

Puedes buscar más información sobre todas estas arquitecturas y aprender un poco más sobres sus principios y sus casos de uso, y no olvides estar atento a nuestro blog, porque trataremos muchas de ellas en próximos posts.

Bibliografia

Arquitectura Limpia. Bob Martin (2018)

JSON Web Tokens

Miguel Ángel Sánchez Chordi — Mon, 11 Sep 2023 07:52:42 +0000

API’s HTTP

Autenticación stateless basada en tokens

Photo by Jaye Haych on Unsplash

Artículo escrito originalmente para Secture&Code

Autenticación y gestión de la sesión en APIs

Una de las principales características de las APIs es su condición de no tener estado, o por su término en inglés: de ser stateless.

¿Qué implica esto? Pues que cada vez que se recibe una petición hay que volver a recrear el estado, incluida la sesión del usuario y su autenticación.

Puede parecer engorroso e innecesario, pero el hecho de ser stateless es la característica principal que nos permite distribuir nuestra API en numerosos servidores sin necesidad de tener las sesiones persistidas de forma distribuida, lo cual sí es un engorro innecesario.

Obviamente, lo que no podemos hacer es solicitar al usuario que se autentique con cada petición que tenga que hacer al API, ya que esto sería una experiencia de uso nefasta. Para ello la solución más común es utilizar un sistema de autenticación basado en tokens. Veamos un par de ejemplos:

Tokens JWT

Las siglas JWT provienen de JSON Web Tokens, y tal y como indica su nombre son unos tokens basados en JSON. En realidad se trata de un estándar abierto que define una forma compacta y autocontenida para transmitir de forma segura información entre backend y frontend en forma de objeto JSON. Es segura porque esta información puede ser verificada y confiada ya que viene firmada digitalmente. Los tokens JWT puede firmarse mediante el algoritmo HMAC o mediante un sistema PKI de claves públicas y privadas basadas en RSA o ECDSA.

Opcionalmente estos tokens pueden ser encriptados para ocultar la información durante la transmisión entre ambas partes. La firma del token permite verificar la integridad de la información contenida en él, y al realizarse mediante claves públicas y privadas, garantiza que solo el holder de la clave privada ha podido emitir esa información.

Veamos un ejemplo de un _token _JWT:

Como se puede observar hay una estructura de tres elementos separados por puntos, tal que así:

xxxxxxxxxx.yyyyyyyyyy.zzzzzzzzzz

Cada una de estas secciones, codificadas en base64, son respectivamente:

Header (Cabecera)
Payload (Cuerpo)
Signature (Firma)

Al realizar la decodificación de cada uno de estos elementos podemos ver el contenido de la cabecera y el cuerpo (la firma no va codificada):

Header

Habitualmente la cabecera se compone de dos elementos: el tipo (typ) que siempre en este caso es JWT, y el algoritmo que se usa para verificar la firma.

Payload

El cuerpo por su parte se compone de una serie de atributos (o claims) registrados (sub, iss, exp, iat…) privados (admin…) y públicos (name).

La lista de claims registrados puede consultarse en la especificación oficial. Usualmente se componen solo de tres letras, ya que se supone que el token debe de ser compacto. Veamos algunos de ellos:

iss: issuer o quién ha emitido el token.
sub: subject o el motivo por el que se ha emitido el token.
exp: expiration, la fecha en que expirará el token. Habitualmente en forma de timestamp.
iat: issued at, la fecha en que se emitió el token. Habitualmente en forma de timestamp.
aud: audience, el público a quien va dirigido el token.

Usualmente el claim más usado es el de exp, ya que en muchos casos el resto son irrelevantes, pero la fecha de caducidad siempre es importante.

Los claims privados son todos aquellos que nosotros queramos incluir: nombre, email, id… todo cuanto necesitemos.

Los claims públicos pueden ser definidos por los usuarios de JWT, pero para evitar colisiones estos deben de estar registrados en el Registro IANA de JSON Web Tokens.

Signature

Realizar la verificación de la firma es tan sencillo como utilizar la clave privada para firmar ese par de cabecera/cuerpo, y comprobar que coincide con la que nos envían para garantizar que el firmante está en posesión de la clave privada para realizar la firma.

Uso del token

Tras realizar login con el API, esta nos devuelve un token similar al que hemos visto antes, la forma de utilizar estos tokens es incluirlos con la cabecera Authorization de este modo:

**Authorization:** Bearer eyJhbGciOiJSUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.jYW04zLDHfR1v7xdrW3lCGZrMIsVe0vWCfVkN2DRns2c3MN-mcp_-RE6TN9umSBYoNV-mnb31wFf8iun3fB6aDS6m_OXAiURVEKrPFNGlR38JSHUtsFzqTOj-wFrJZN4RwvZnNGSMvK3wzzUriZqmiNLsG8lktlEn6KA4kYVaM61_NpmPHWAjGExWv7cjHYupcjMSmR8uMTwN5UuAwgW6FRstCJEfoxwb0WKiyoaSlDuIiHZJ0cyGhhEmmAPiCwtPAwGeaL1yZMcp0p82cpTQ5Qb-7CtRov3N4DcOHgWYk6LomPR5j5cCkePAz87duqyzSMpCB0mCOuE3CU2VMtGeQ

La palabra clave Bearer indica que es un token autocontenido. Mientras el token sea válido (el atributo exp contiene la fecha de caducidad) el API nos dará acceso a la sesión del usuario logueado.

Refresh Tokens

Habitualmente el TTL (time to live) o duración del token, es relativamente corto, ya que cualquiera que tenga el token podría impersonar la sesión. El problema es que no podemos estar pidiéndole cada dos por tres al usuario que se autentique, por lo que tenemos que ser creativos y buscar una alternativa.

La alternativa preferida es el uso del refresh token. El refresh token es un token que nos permite obtener un nuevo token de sesión sin necesidad de volver a introducir los credenciales del usuario. Por normal general el refresh token tiene una duración muy superior a la del token de sesión, y es responsabilidad del frontend almacenarlo de la manera más segura posible.

Al contrario que los tokens de sesión, estos se guardan en base de datos y pueden invalidarse manualmente, por lo que si somos conscientes o sospechamos que hubo un robo del token, podemos invalidarlos y dejar al atacante sin posibilidad de seguir utilizándolo.

Además de esto, podemos tomar precauciones extra, como asociarlo a una IP en concreto o cualquier otra medida que nos parezca apropiada.

Basic Auth

Esta es una forma de autenticación totalmente desaconsejada, ya que implica almacenar temporalmente la contraseña del usuario para realizar la autenticación.

Básicamente consiste en realizar una codificación en base64 del nombre del usuario junto con su contraseña, separados por el carácter de los dos puntos y enviarlo en la cabecera Authorization.

Supongamos que el usuario es admin@secture.com y la contraseña p4ssW0rD entonces la cadena a codificar sería:

admin@secture.com:p4ssW0rD

Daría como resultado:

YWRtaW5Ac2VjdHVyZS5jb206cDRzc1cwckQ=

Y la usaríamos de esta manera:

**Authorization:** Basic YWRtaW5Ac2VjdHVyZS5jb206cDRzc1cwckQ=

En este caso la palabra clave Basic indicaría el tipo de autenticación.

Como se puede ver, es muy sencillo que un potencial atacante esnife el tráfico y obtenga la contraseña de nuestro usuario con una simple decodificación del token.

Conclusión

Al tratar con APIs sin estado necesitamos hacer uso de algún método para recrear la sesión del usuario. Actualmente existen varias alternativas. Aquí hemos visto dos, pero solo recomendamos el uso de JWT, ya que es un estándar abierto, enfocado en la seguridad y la integridad de los datos y ampliamente usado en producción.

La autenticación básica es solo un remanente de épocas pasadas que está condenado a desaparecer, ya que es totalmente inseguro.

¡Desde Secture te animamos a dejar comentarios explicando qué otros medios usas para controlar las sesiones de los usuarios de tu API!

Bibliografía:

Patrón Money

Miguel Ángel Sánchez Chordi — Tue, 29 Aug 2023 09:24:19 +0000

Maneja correctamente el dinero en tu aplicación y prepárala para el escalado internacional

Photo by Jason Leung on Unsplash

Artículo publicado originalmente para Secture&Code

Trabajar con cantidades de dinero nunca ha sido un asunto sencillo: redondeos, cambios de divisa… una mala gestión puede derivar en perdidas para nuestra empresa o en cobrar de más a nuestros clientes, con el consiguiente perjuicio reputacional.

El patrón Money

Martin Fowler publicó en 2002 su famoso libro Patterns of Enterprise Application Architecture, donde uno de los patrones incluidos era el llamado patron Money. Con este patrón, Fowler pretende simplificar la gestión de cantidades monetarias y reducir los posibles riesgos que antes comentábamos.

El patrón Money se basa en otro patrón conocido como Value Object, y consiste en modelar un pequeño objeto que represente una cantidad monetaria. Para ello se usan dos atributos: la cantidad (amount), y la moneda (currency), y una serie de operaciones lógicas y matemáticas:

Diagrama UML del Patrón Money

Atributos

amount: es el importe, representado siempre en la unidad mínima de la moneda asociada. Esta representación es perfecta para realizar comparaciones entre cantidades de una misma moneda, ya que las comparaciones entre números en coma flotante siguen siendo un asunto sin resolver en cualquier lenguaje.

Es importante saber que no todas las monedas son como el dólar o el euro, ya que no en todas la unidad mínima es el céntimo. Existen monedas donde la propia moneda es la unidad mínima, y otras donde no sólo tienen céntimos, sino que tienen unidades más pequeñas que el céntimo.

Ejemplos de estos casos son el dinar de Bahrain, con milésimas partes del dinar, o el peso de Chile, donde no hay unidades inferiores al peso.

Podemos consultar una lista con todas las monedas este enlace.

currency: es el código ISO-4217 de la moneda con la que estamos trabajando. Es un código de 3 letras que representa la moneda de forma internacional, por ejemplo EUR para Euros.

Métodos / Operaciones

+, -, *, / : operaciones matemáticas básicas, como la suma, resta, multiplicación, división…
allocate: una operación especial destinada a dividir una cantidad de dinero entre dos o más receptores. Luego entraremos más en detalle.
*<, >, ≤, ≥, = * : operaciones lógicas básicas, como menor que, mayor que, menor igual que, mayor igual que, igual…

Ejemplos

Queremos representar la cantidad 528.75€, cuya unidad mínima es el céntimo de euro:

amount: 52875
currency: EUR

Queremos representar la cantidad 528.75.د (dinares de Bahrain), cuya unidad mínima es la milésima parte de un dinar.

amount: 528750
currency: BHD

Para representar visualmente la cantidad, solo necesitamos aplicar la sencilla fórmula: amount / (10 x unidad mínima).

Implementación

Es sencillo realizar una implementación básica de este patrón, lo realmente tedioso es tener actualizada siempre la lista de monedas, con sus unidades mínimas o sus ratios de conversión.

Veamos una implementación sencilla en PHP:

Patrón Money básico en PHP

A esta implementación básica le faltarían todos los métodos de las operaciones lógicas y matemáticas. He querido dejar de lado esta implementación para poder comentar que podemos hacerlo en dos versiones distintas:

Orientado a objetos: añadiendo los métodos add, substract, multiply, divide… Este sería el estilo orientado a objetos clásico. Nos permitiría tomar dos enfoques: mutable (modifica la instancia actual) o inmutable (no modifica la instancia, devuelve una nueva). De esta manera podremos ejecutar cosas como:

Sobrecarga de operadores: muchos lenguajes orientados a objetos, como Java, PHP, Python o Ruby permiten lo que llamamos sobrecarga de operadores, que no es más que permitir cambiar el comportamiento de los operadores aritméticos y lógicos cuando estos son aplicados a objetos de cierta clase, y no a tipos primitivos como se hace habitualmente. Esto nos permitiría sobrecargar los operadores de tal manera que podríamos ejecutar algo así como:

La implementación básica de este patrón es realmente muy sencilla, pero si queremos sacarle el máximo provecho tenemos implementaciones en casi todos los lenguajes, que además cubren otros aspectos como la representación visual de la cantidad (situar el símbolo monetario a la derecha o a la izquierda), o la conversión entre divisas.

Algunas implementaciones conocidas:

PHP: https://github.com/moneyphp/money
Ruby: https://github.com/RubyMoney/money
Python: https://github.com/poswald/python-money

Método allocate

Este método, como ya comentamos antes, es un método especial usado para distribuir adecuadamente una cantidad entre dos o mas receptores cuando no puede hacerse de forma exacta (sin sobras). Por ejemplo cuando lo hacemos basándonos en porcentajes o ratios.

Veamos un caso específico:

Queremos repartir 5cts de euro entre dos cuentas al 30%-70%. Esto implica un reparto de 1,5cts y 3,5cts. El problema es que el céntimo es la unidad mínima de la divisa euro, y no podemos partir un céntimo en dos, por lo tanto el reparto exacto no puede hacerse.

La solución más habitual es repartir 1 céntimo a cada recipiente mientras no hayan llegado a la cantidad justa. Una vez haya sobrepasado esa cantidad, deja de recibir dinero.

Recipiente A: 1.5cts

Recipiente B: 2.5cts

Recipiente A: 1cts (1 < 1.5 ✅). Recipiente B: 1cts (1 < 2.5 ✅)
Recipiente A: 2cts (2 < 1.5 ❌). Recipiente B: 2cts (2 < 2.5 ✅)
Recipiente B: 3cts (3 < 2.5 ❌)

Recipiente A: 2cts

Recipiente B: 3cts

Bibliografia

Command Query Responsibility Segregation | CQRS

Miguel Ángel Sánchez Chordi — Fri, 04 Aug 2023 14:11:41 +0000

Prepara tu código para escalar hasta el infinito

El patrón CQRS fue descrito por Greg Young en 2010 como una forma de separar los modelos de escritura (commands) y de lectura (queries) de nuestras aplicaciones, permitiendo de este modo un escalado asimétrico entre los mecanismos de lectura y escritura de nuestra aplicación.

La idea básica es que podemos utilizar un modelo para escribir, distinto al modelo que usamos para ejecutar lecturas, como contrapunto al habitual CRUD ( C reate, R ead, U pdate, D elete). Cabe decir que esta aproximación, la de CQRS, puede añadir una mayor complejidad que un sistema sencillo basado en CRUD.

Implementación de CQRS

Separación de los modelos

Podemos implementar CQRS de distintas maneras en función de nuestras necesidades.

Por ejemplo, podemos optar por mantener una única base de datos y realizar solo una separación a nivel de conexión, es decir, usaremos una conexión diferente para las operaciones de lectura (queries) y las de escritura (commands). Esto nos permiten configurar distintos parámetros como timeouts, tamaño de peticiones y otros parámetros más ajustados a la naturaleza de la operación.

CQRS con base de datos unificada

Esta aproximación tiene el inconveniente de que la separación solo existe a un nivel lógico, es decir, seguimos atacando la misma base de datos, por lo que sigue siendo el mismo sistema el que asume la carga de trabajo.

Otra aproximación sería utilizar dos bases de datos separadas para escrituras y lecturas:

CQRS con bases de datos separadas

De este modo, la carga de las operaciones de lectura y escritura están más repartidas y no solo a un nivel lógico, sino que son dos sistemas diferentes los que manejan esta carga. El inconveniente de esta aproximación es que se genera una consistencia eventual, es decir, los modelos de lectura y escritura no serán consistentes en todo momento, sino que eventualmente existirán diferencias entre ellos, lo cual puede generar un problema en función de la naturaleza de los datos.

Implementación de los modelos

Al implementar las operaciones de lectura y escritura vamos a tener 3 nuevas parejas de actores:

Query y QueryHandler. Son, respectivamente, el modelo de lectura y su manejador. La query no es más que un DTO con toda la información necesaria para realizar la lectura (parámetros, filtros, paginación…). Por su parte el handler o manejador es el servicio encargado de obtener esa información y devolvérsela al controlador. Por norma general, las operaciones de lectura son siempre síncronas.

La correspondencia de queries y handlers es 1:1, es decir, cada query tiene solo un handler, no puede ser manejado por más de uno.

Command y CommandHandler. Son respectivamente el modelo de escritura y su manejador. El command no es más que un DTO con toda la información necesaria para realizar la escritura (identificador del registro(s) a editar, atributos a modificar…). Por su parte el handler o manejador es el servicio encargado de persistir esa información. Las operaciones de escritura pueden ser síncronas o asíncronas, lo cual representa una ventaja en términos de eficiencia, ya que podemos simplemente lanzar la acción de actualización sin esperar a que ésta acabe: el frontend ya tiene los datos actualizados, ya que es él quien nos los ha mandado. Debemos de tener, eso sí, mecanismos para reaccionar de cara a problemas de escritura de datos asíncronos (sistema de reintentos, notificaciones al frontend vía server push o sockets…).

La correspondencia de commands y handlers es 1:1, es decir, cada command tiene solo un handler_, no puede ser manejado por más de uno._

Event y EventHandler. En este caso son, respectivamente, el modelo de algo que ha sucedido en nuestro sistema y su manejador. El event no es más que un DTO con la información de lo que ha sucedido, normalmente se compone de una fecha o timestamp de cuándo ha ocurrido, un nombre descriptivo, siempre en pasado, de lo sucedido (por ejemplo: user_deleted) y un cuerpo o payload con toda la información relevante para manejar el evento. Este payload puede componerse de datos necesarios para identificar el registro afectado, los atributos que se han modificado… etc. Al igual que los commands, los eventos pueden manejarse de forma síncrona o asíncrona, asegurándonos de tomar las mismas precauciones para gestionar posibles errores.

Al contrario que en los casos anteriores, la correspondencia de eventos y handlers (o listeners) es 1:n, es decir, cada event tiene más de un handler o listener.

Un caso de uso muy común de los eventos es eliminar la consistencia eventual producida en sistemas con bases de datos separadas: tras realizarse una actualización, eliminación o inserción de datos en la base de datos de escritura, un evento avisa de los cambios para que estos se repliquen en la base de datos de lectura.

Actualización del modelo de lectura mediante eventos

Manejo síncrono o asíncrono de los modelos

Para permitir el manejo síncrono o asíncrono de los modelos solemos hacer un uso de un sistema intermedio que se encarga de emparejar los commands, las queries y los events con sus respectivos handlers. Este sistema intermedio es lo que llamamos un bus. El bus es como una cola donde metemos los commands, queries o events y estos son ejecutados por sus handlers asociados. Este bus puede implementarse con sistemas como Message Queues Systems (RabbitMQ) o sistemas como Redis que permiten el encolado de tareas.

Flujo síncrono de un endpoint para obtener una entidad de base de datos

La ventaja del uso de buses en forma de colas de mensajes es que añadimos una capa de indirección entre la acción y la ejecución. Esto quiere decir que la tarea encolada puede ser consumida por nuestro propio sistema o por un sistema externo que se conecte al servicio de colas, permitiéndonos esto el tener sistemas externos encargados de manejar, por ejemplo, la consistencia eventual, o delegar tareas largas y pesadas a sistemas expertos en realizar estas mismas tareas, que puede que ni siquiera estén escritos en el mismo lenguaje que nuestro sistema principal.

Flujo asíncrono de un endpoint de actualización de un registro que incluye el disparo de un evento.

Veamos un ejemplo de como nuestro sistema podría manejar la consistencia eventual (sin el uso de agentes externos):

Manejo de la consistencia eventual con eventos en un sistema de buses.

En el ejemplo de arriba vemos como el command handler dispara un evento al bus de eventos. Este evento puede ser la notificación de que se ha escrito un nuevo registro, o que se ha editado o eliminado uno que ya existía previamente. Puede representar más cosas, como que se ha suscrito a un servicio, que ha hecho like a una foto… lo que sea. El tema es que este evento es capturado por el handler asociado y actúa en consonancia actualizando la base de datos de lectura, tratando de reducir al máximo el tiempo de consistencia eventual.

Ventajas de CQRS

Escalado asimétrico. En entornos de alta disponibilidad, donde se producen miles de interacciones por segundo y hay flujos con más tráfico que otros, el escalado asimétrico de nuestra plataforma es algo realmente deseable, ya que podemos centrar el esfuerzo económico en esa parte únicamente. En el caso de CQRS, el tener separados los dominios de escritura y los de lectura nos permite centrar nuestros esfuerzos económicos en el que requiera mayor inversión. ¿Tenemos un proyecto tipo red social donde la gente se pasa más tiempo leyendo contenido que produciéndolo? Incrementamos las instancias de lectura, escalamos las instancias… lo que sea necesario, pero sólo centrado en las de lectura. ¿Nuestro proyecto es como un API en la que sensores a lo largo de cientos de instalaciones escriben registros cada segundo o minuto? Nos centramos en escalar la escritura, ya que, seguramente, haya poca gente consultando el panel de lecturas si lo comparamos con el número de escrituras.
Separación de dominios más semántica. Esta ventaja es más a nivel organizativo, pero el hecho de tener separados nuestros casos de uso entre lecturas y escrituras simplifica mucho el entendimiento del mismo. Por ejemplo, sabemos seguro que una lectura no va a tener side effects o que podemos ejecutarla tantas veces como queramos sin repercusiones. Luego, la separación de los side effects que puedan producir las escrituras, al manejarse con eventos nos permite centrar el caso de uso en su propósito único, y delegar estos side effects a otras porciones de código, quedando todo mucho más limpio y organizado.

Inconvenientes de CQRS

Complejidad. El hecho de tener que implementar CQRS incrementa notablemente la complejidad de nuestro sistema, tanto por tener el doble de configuraciones o instancias de base de datos, como por la necesidad del uso de buses (aunque esto es realmente opcional). Si no estamos acostumbrados a trabajar por capas puede ser un cambio realmente brusco, aunque a medio/largo plazo la situación mejora ostensiblemente. Un problema derivado de la complejidad es que necesitamos un equipo senior formado para diseñar nuestra estrategia y montar un flow de trabajo que luego puedan seguir nuestros compañeros más juniors, pero un buen diseño puede derivar en un proceso casi mecánico para implantar nuevos casos de uso basados en commands y queries.
Consistencia eventual. Éste es el verdadero gran inconveniente de CQRS, ya que, dependiendo de lo urgente que sea tener nuestros datos actualizados, puede ser una buena opción o no, debido a que tendremos que garantizar un tiempo mínimo para que sean consistentes ambas bases de datos. Luego derivado de esto pueden darse problemas con la entrega de datos de los buses, que pueden llegar repetidos o desordenados, y es algo que también tenemos que controlar.

A continuación veremos una técnica para facilitar la gestión de la consistencia eventual llamada Event Sourcing.

Consistencia eventual y Event Sourcing

Event Sourcing es un patrón o técnica que podemos utilizar para tratar de simplificar los problemas de consistencia eventual, así como añadir una serie de beneficios a nuestro sistema, tales como:

Observabilidad. Sabemos por qué un registro está en el estado que está.
Tolerancia a fallos. Podemos reconstruir los registros a partir de los eventos guardados.
Auditoria. Estrechamente relacionado con la observabilidad, nos permite auditar las acciones que tienen lugar en nuestro sistema y podemos determinar flujos de datos erróneos.

¿En qué consiste el Event Sourcing?

Es un patrón mediante el cual registramos en una base de datos separada o event store todos los eventos que se producen en nuestro sistema, de modo que formen un histórico de cambios asociado a un registro de nuestra base de datos. Esto nos permite reconstruir un registro a cualquier momento del flujo de vida de nuestro sistema.

Cadena de eventos producida por command handlers y consumidos por la base de datos de lectura para recrear el estado de un registro.

Los eventos, por supuesto, deben de guardar la fecha en la que fueron lanzados, ya que esta es la que determinara su orden en la cadena. También es importante que guarden el identificador del registro de base de datos al que pertenecen, de modo que cuando queramos recrear un registro o desplazarnos hasta un momento en el tiempo, es necesario poder identificar el registro en cuestión.

El event sourcing solo se aplica en los modelos de escritura, ya que las lecturas no afectan al estado de los registros.

¿Qué nos aporta CQRS a nosotros?

Para nosotros CQRS ha sido todo un cambio para mejor, ya que nos ha permitido fijar un modo de trabajo común que simplifica mucho el entendimiento de los proyectos, y esto incluye cuando nos movemos entre proyectos en los que no hemos participado nunca.

Aunque de entrada se percibe como un sistema complejo (y lo es), las ventajas que nos aporta a nivel testabilidad, mantenibilidad y escalabilidad de nuestro código (así como la ya mencionada facilidad de rotación entre proyectos), compensan con creces los inconvenientes.

Cabe decir que en proyectos menores hemos tomado decisiones que simplifican todo o que anulan parte de los inconvenientes, como por ejemplo usar comandos síncronos o directamente eliminar los buses de queries y de commands, que borran de un plumazo gran parte de los problemas.

Adaptar los patrones a la necesidad de cada proyecto también es una decisión estratégica que hay que tomar, ya que debemos de estar seguros de sus implicaciones y su facilidad de revertir esas adaptaciones, ya que si un proyecto crece, puede que necesitemos esos extras que nos aporta el patrón original.

Bibliografía

Arquitectura Hexagonal 101

Miguel Ángel Sánchez Chordi — Thu, 20 Jul 2023 11:04:14 +0000

Arquitecturas Limpias

Todo lo que necesitas saber sobre Arquitectura Hexagonal

Esquema de arquitectura hexagonal.

Artículo escrito originalmente para el blog Secture & Code pulsa en el enlace para leerlo.

La Arquitectura Hexagonal, definida por Alistair Cockburn, es una implementación de lo que llamamos una Clean Architecture. Tiene como principal motivación dividir nuestra aplicación en distintas capas con su propia responsabilidad. Esta separación por capas nos permite desacoplar nuestro código de las dependencias externas, como puede ser el framework o cualquier otra librería externa o third party.

Ports and adapters

Esta arquitectura también es ampliamente conocida como arquitectura de puertos y adaptadores, o por su nombre en inglés ports&adapters. Y es justo porque hace un uso intensivo del patrón “adaptador” (Adapter Pattern) junto con el principio de inversión de dependencias para obtener ese desacoplamiento del que antes hablábamos.

¿Por qué hexagonal?

En casi todos los textos o documentos que hablan de esta arquitectura, solemos verla representada con forma de hexágono. ¿Y por qué un hexágono y no un pentágono, o un triangulo o cualquier otro polígono? No hay una respuesta oficial al respecto, simplemente puede ser porque el hexágono es el polígono más versátil. Sea como sea, el número de lados no es relevante, es solo un arreglo meramente cosmético para diferenciarla del resto de arquitecturas limpias.

El hecho es que cada lado representa un puerto de entrada/salida de la aplicación, y una forma poligonal expresa mejor que un círculo este principio.

Estos puertos son el punto de entrada de cualquiera de los agentes externos o mecanismos que pueden interactuar con nuestra aplicación, bien sean estos clientes mobile o web a través del puerto para REST API, navegadores web a través del puerto HTTP o un sistema de colas a través del puerto para Message Brokers.

Cada uno de estos puertos tiene, a su vez, asignado uno o varios adaptadores, en función de la diversidad que queramos soportar. Por ejemplo, el puerto para MessageBrokers podría perfectamente tener adaptadores para RabbitMQ, Redis, Beanstalk o AmazonSQS, si lo que queremos es dar soporte a toda esta variedad de providers.

Puntos en común con Clean Architecture

Anteriormente ya hablamos de Clean Architectures y sus características, por lo que sería recomendable echar un vistazo al post en el que hablamos de este tema, ya que la arquitectura hexagonal es una de las implementaciones más puras que podemos encontrar de Clean Architecture.

Tanto la distribución de las capas como su contenido o las reglas de dependencia son literalmente las mismas, pero igualmente vamos a ver sus características.

La regla de dependencia

Cada uno de los hexágonos concéntricos representa una capa, y esta capa a su vez es una barrera que sólo puede ser atravesada por sus capas superiores. De este modo:

Infraestructura puede acceder a Aplicación y a Dominio
Aplicación puede acceder a Dominio
Dominio sólo puede acceder a Dominio

Estructura de directorios y separación por capas

Vamos a ver paso por paso la estructura de directorios y cómo se distribuye el código en las distintas capas. Empezaremos por un ejemplo básico que iremos iterando.

En primer lugar, la raíz de nuestro proyecto podría ser esta:

Raíz del proyecto

apps contiene las aplicaciones, las instalaciones de los distintos frameworks que usemos. Aquí es donde vivirán nuestros controladores y nuestras rutas.
src contendrá nuestro código, la lógica de negocio de nuestra aplicación.

Aplicación API

Aquí podemos observar desplegado el contenido de una aplicación. Por razones de espacio hemos obviado toda carpeta no relevante, dejando a la vista solo el entrypoint (index.php) y los controladores.

Contexto y módulos de API

Hemos optado por una distribución en contextos (API y Shared). En este caso solo tenemos un contexto funcional (API) y otro compartido (Shared), pero podríamos tener más como, por ejemplo, backoffice, que podría contener todo el código para gestionar una aplicación de gestión de contenidos.

Como se puede apreciar, cada módulo contiene su tripleta de carpetas, correspondiente cada una a una de las capas de la arquitectura.

Módulo Users expandido

Entrando más en detalle, podemos ver el contenido de cada una de las carpetas que conforman la arquitectura:

Application. Casos de uso. En nuestro caso aplicamos CQRs, por lo que normalmente se componen de una query (acción de lectura) o un command (acción de escritura), un handler o manejador y, opcionalmente, un servicio que ejecute la acción. En algunos casos este servicio puede ser compartido por otros casos de uso, como por ejemplo en el caso de GetUser, por lo cual promocionamos el servicio de application service a domain service, situándolo en la carpeta Domain y haciéndolo accesible al resto de casos de uso.
Domain. Aquí es donde alojamos los objetos de dominio, como la entidad User que representa a un usuario, o los contratos de servicios que se implementarán en infraestructura, como UserRepository. También consideramos objetos de dominio las excepciones, y algunos servicios compartidos como el anteriormente citado GetUser.
Infrastructure. Por último tenemos las implementaciones de los contratos de dominio. En este caso solo tenemos una implementación del repositorio y sería para el motor de bases de datos MySQL, pero perfectamente podríamos soportar más con solo implementar el contrato.

Contexto compartido expandido

Antes hablábamos de un contexto compartido, y es aquí donde van la mayor parte de los contratos y de las implementaciones de elementos que se van a utilizar por toda la aplicación, como pueden ser por ejemplo un EventDispatcher, o los buses de commands y queries. En este ejemplo, hemos implementado un bus con dos proveedores diferentes: Symfony y Tactician. Y, además, hemos realizado dos implementaciones diferentes para cada una: la versión síncrona y la asíncrona.

Con esto pretendemos demostrar la versatilidad que nos ofrece esta arquitectura y la facilidad de cambio que nos aporta a nuestro código: podríamos cambiar la forma en que se manejan nuestros commands y nuestras queries con solo alterar unos parámetros de configuración del container de dependencias.

Arquitectura hexagonal y DDD

Habremos visto mil y una veces el termino de arquitectura hexagonal junto con el de DDD, y es que sin duda son un killer combo muy socorrido.

El DDD es una metodología de desarrollo que defiende el desacoplamiento por encima de todo, por lo que la Arquitectura Hexagonal encaja como un guante como núcleo central en su práctica.

Bibliografia

APIs HTTP

Miguel Ángel Sánchez Chordi — Sun, 13 Nov 2022 11:40:47 +0000

Expón tus APIs al mundo entero

Si hay un concepto en el mundo del desarrollo que haya cobrado fuerza estos últimos años, sin duda es el término API.

No hay proyecto que se precie que no tenga su API, pública o privada, o que haga uso de APIs de terceros para obtener información o integrar servicios de una forma mas o menos sencilla.

Pero, ¿qué es una API?

Las siglas API corresponden al término Application Programming Interface, que podríamos traducir como interfaz de programación de aplicaciones. Y es que un API no es más que un conjunto de funciones que nos ofrece un sistema, y que nosotros, combinándolas de forma adecuada, nos permite crear aplicaciones o nuevas funcionalidades.

Tipos de APIs

Pero una API no sólo puede tener la forma de un servicio HTTP, el concepto es mucho más amplio que eso. Por ejemplo, en el paradigma de la programación orientada a objetos (POO), el conjunto de métodos públicos de una clase se puede considerar su API.

Cuando descargamos una biblioteca de terceros en nuestro proyecto, el conjunto de servicios y funciones que podemos usar es también el API de esta biblioteca.

Si desarrollamos aplicaciones para Android, iOS, Linux, Windows, MacOS… estos sistemas ofrecen APIs que nos permiten interactuar con sistema para que podamos hacer cosas como abrir ventanas, capturar notificaciones del sistema, integrar nuestra app con el sistema para que tenga un aspecto nativo, incluir nuevas acciones en menús… etc.

Y, por supuesto, el conjunto de endpoints que nos permite interactuar con un servicio HTTP, es también un API. En este caso un API HTTP.

APIs HTTP

El concepto de API es el mismo, pero en este caso las funcionalidades en lugar de estar en una biblioteca que hemos importado o ser parte de un sistema para el que queremos desarrollar, están en un servidor externo que nos ofrece estas funcionalidades y la forma de comunicarnos con el servidor es a través del protocolo HTTP.

Dada esta característica, es muy importante conocer cómo funciona el protocolo HTTP, ya que entender los pormenores de HTTP nos va a permitir comprender el funcionamiento de la API.

Vamos a dar un repaso rápido a los conceptos más importantes del protocolo HTTP.

Protocolo HTTP

El protocolo HTTP es un protocolo de comunicación de red. Está basado en peticiones y respuestas (requests y responses) que deben de seguir un formato en concreto. Es un protocolo no orientado a conexión , es decir, tras obtener la respuesta a una petición, la conexión se cierra en lugar de mantenerse a la espera de recibir más peticiones. Dicho de otro modo: no mantiene el estado.

Es un protocolo multimedia, ya que admite distintos formatos tanto en los datos de petición como de respuesta: HTML, CSV, JSON, XML, imágenes, PDFs, audio, video…

Esquema del protocolo HTTP

URLs

La URL es posiblemente el componente más importante de HTTP, ya que es la cadena que va a representar una dirección. Las siglas URL vienen de Uniform Resource Locator, o localizador uniforme de recursos en castellano plano. Como su nombre indica, es un localizador de recursos, una cadena que nos permite identificar un recurso de forma unívoca. Veamos sus partes:

Esquema completo de una URL

Protocolo o esquema: esta parte es obligatoria e indica el protocolo o servicio que vamos a utilizar. Puesto que las URLs se usan en otros protocolos, como FTP, SSH, NFS y muchos otros más, indicar el protocolo es imprescindible. Además, cada protocolo tiene definido un puerto por defecto, por lo que si no ha cambiado por algún motivo, podremos ahorrarnos poner el puerto en la URL. En el caso que nos atañe, el protocolo será HTTP o HTTPS (la versión cifrada del protocolo HTTP).
Usuario y contraseña: aunque no es muy común, podemos utilizar la propia URL para autenticarnos, aunque a la vista salta de que no es muy seguro. Esto suele utilizarse más en otros protocolos, pero no está de más saber que esto existe. El usuario y la contraseña se separan mediante el carácter de los dos puntos o colon. La arroba (@) se utiliza para separar la contraseña del dominio. Esta parte es, obviamente, opcional.
Dominio y TLD: el nombre de dominio es la parte más común de una URL e indica el servidor al que queremos conectarnos. Se compone de 3 partes: — Subdominio: es opcional. Normalmente indica distintos servicios o funciones dentro de un mismo servidor: www, ftp, api, assets… etc.. — Dominio: es la parte más conocida, el nombre del servidor al que nos conectamos: Google, Amazon, Microsoft… — TLD: Top Level Domain, es decir, los ya conocidos .es, .com, .net… El dominio y el TLD son obligatorios.
Puerto: habitualmente esta parte de la URL va implícita con el protocolo, pero en ocasiones (por ejemplo en desarrollo) es posible que estemos utilizando un puerto distinto para servir nuestro servicio. La manera correcta de indicar el puerto es mediante el carácter de los dos puntos o colon y el número de puerto. Esta parte es opcional, como ya hemos dicho.
Ruta, path o URI: es la cadena que identifica un recurso dentro del servicio. En ocasiones oiremos que se refieren a ella como URI (Universal Resource Identifier) o path. Habitualmente es una cadena separada por barras que indica la ubicación de un recurso. Esta parte es obligatoria, aunque si no la incorporamos se asume que estamos accediendo a la raíz, representada por la barra /.
Anclaje, anchor o fragment: esto solo tiene sentido dentro del contexto de la web (HTML para ser más exactos). Se utiliza para indicar a qué sección dentro de un documento queremos hacer referencia con la URL. Es totalmente opcional.
Parámetros o query string: es un conjunto de variables que le pasamos la URL. Habitualmente con la intención de parametrizar la respuesta, como, por ejemplo, en el caso de usar paginación. Para indicar que empezamos a pasar parámetros se usa el carácter ?, y para separar un parámetro de otro se usa el carácter &. Esto es totalmente opcional.

Peticiones

Como su nombre indica, una petición es el acto de requerir a un servicio que realice cierta acción y nos responda con el resultado.

En el caso de las peticiones HTTP, estas se componen de:

Verbo: indica el tipo de acción a realizar, lo veremos en profundidad más adelante.
URL: ruta a la que estamos solicitando la acción.
Cabeceras: son unos parámetros que nos dan información sobre la propia petición o sus requisitos. Podemos, por ejemplo, especificar en qué formato queremos la respuesta o en qué idioma. Mas adelante entraremos en profundidad sobre este tema.
Cuerpo: en el caso de las peticiones de escritura, aquí es donde va el contenido de nuestra petición. Puede estar en distintos formatos, pero tenemos que especificar mediante una cabecera qué formato hemos utilizado.

Respuestas

Como contraparte a una petición, tenemos la respuesta. La respuesta sigue un formato muy similar a la petición, solo que en este caso no incorpora un verbo, pero sí un código de estado (status code) que define el resultado de la petición. Obviamente, la respuesta sigue incluyendo un cuerpo con los datos que hayamos solicitado o información extra, el código de estado es una forma de clasificar la respuesta.

Veamos qué elementos componen una respuesta HTTP:

Código de estado (status code): indica el tipo de respuesta. Entraremos en detalle más adelante.
Cabeceras: son unos parámetros que nos dan información sobre la propia respuesta, como por ejemplo su formato, idioma, dirección del nuevo recurso creado u otras relacionadas con la caché.
Cuerpo: en el caso de las respuesta a peticiones de lectura, aquí es donde va el contenido solicitado. Puede estar en distintos formatos, pero tenemos que especificar mediante una cabecera qué formato hemos utilizado.

Cabeceras

Como ya hemos comentado, las cabeceras son tanto parte de las peticiones como de las respuestas, y éstas sirven tanto para aportar información de las mismas, como para configurarlas. Por ejemplo, mediante cabeceras de petición podemos indicarle al servidor qué formato de respuestas queremos (Accept), o en qué idioma (Locale), en qué formato estamos enviando datos (Content-Type), de dónde venimos (Referrer) o incluso quiénes somos (Auth) y qué cliente usamos (User-Agent). Con las respuestas podemos hacer lo mismo, e incluir, además, información acerca del servidor (Server), la compresión utilizada (Content-Enconding), la cache (Cache-*) y un largo etcétera.

Las archiconocidas cookies también se incluyen en las cabeceras, tanto de las respuestas como de las peticiones.

Si nos quedamos cortos de cabeceras para lo que necesitamos, siempre podemos definir nuestra propias cabeceras prefijando X- al nombre de nuestra cabecera (aunque es una práctica desaconsejada).

Podemos consultar una lista de todas las cabeceras disponibles en Wikipedia — List of HTTP headers

Códigos de estado

Los códigos de estado son unos valores numéricos incluidos en las respuestas que nos ayudan a determinar si la respuesta ha sido exitosa, fallida por culpa de la petición o fallida por culpa del servicio.

Los códigos de estado se agrupan en 5 bloques:

División en grupos de los códigos de estado

Como se puede apreciar en el gráfico de arriba, estos 5 bloques de códigos de estado se diferencian por el primer dígito, que es el que indica que tipo de respuesta hemos obtenido. Los siguientes dos dígitos nos aportan información más específica sobre la respuesta. Vamos a ver algunos ejemplos.

1xx Informacionales

100 Continue
101 Switching Protocols

2xx Éxito

200 OK
201 Created
202 Accepted
204 No Content
206 Partial Content

3xx Redirection

301 Moved Permanently
302 Found
304 Not Modified

4xx Error de Cliente

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
409 Conflict
412 Precondition Failed
413 Request Entity Too Large
415 Unsupported Media Type
422 Unprocessable Entity
428 Precondition Required

5xx Error de Servidor

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported

Se puede consultar una lista más completa en este enlace: RestApiTutorial — Status Codes o en Wikipedia — Status Codes

Verbos

Ahora que ya hemos hablado de las URLs vamos a ver cómo interactuar con ellas. El protocolo HTTP se sirve de un conjunto de verbos o acciones que se deben de utilizar en función del tipo de petición que queramos llevar a cabo, como, por ejemplo, una lectura de datos o una escritura.

Vamos a ver los verbos más comunes:

GET. Se usa para leer contenidos. Es muy habitual que las URLs consultadas mediante GET admitan parámetros de query string. Estas peticiones carecen de cuerpo de petición.
POST. Esta es la petición que se utiliza para crear nuevos recursos. Es la única operación no idempotente, es decir, si la ejecutamos más de una vez, el estado de nuestro sistema habrá cambiado (habremos creado dos recursos), algo que no sucede con el resto de verbos. Es por esto, entre otras cosas, que las peticiones POST no pueden ser cacheadas. Las peticiones POST tienen cuerpo o body, y es ahí donde va la información que utilizaremos para escribir el nuevo recurso.
PUT. Al igual que POST, esta petición escribe datos, pero en este caso para actualizar un recurso de forma completa, es decir, reemplazar su contenido por el que viene en el body o cuerpo de la petición.
DELETE. Es el verbo que utilizamos cuando queremos eliminar un recurso.
PATCH. Es similar a PUT, pero a diferencia de PUT no reemplaza el recurso por completo, sino que sólo lo modifica parcialmente. Es necesario especificar un formato de petición que indique los cambios que van a realizarse sobre el recurso. Actualmente no hay un estándar para ello y es un verbo poco utilizado.
HEAD. Hay ocasiones en las que solo nos interesa conocer el resultado de una petición GET sin ver su contenido. Con el verbo HEAD podemos obtener solo el código de estado de una petición. Esto puede ser útil, por ejemplo, para determinar si un recurso existe o no sin necesidad de obtenerlo.
OPTIONS. Este verbo nos permite conocer de una URL que verbos admite, es decir, si podemos realizar GET, POST y PUT, o solamente POST, o solamente GET o cualquier combinación posible.

Otros aspectos de un API HTTP

Una de las principales características de las APIs que hemos mencionado antes es que son multimedia y eso quiere decir que admite distintos formatos tanto en los datos de petición como de respuesta: HTML, CSV, JSON, XML, imágenes, PDFs, audio, video…

Veamos algunos ejemplos.

Formatos de petición

Las peticiones suelen seguir formatos de entrada simples, habitualmente JSON o XML, aunque perfectamente podría ser YAML, TOML, CSV o cualquier tipo de fichero.

La ventaja de JSON o XML es que son formatos suficientemente estructurados como para representar la información de una manera relativamente comprensible para una persona y fácilmente procesable para una máquina.

El formato de la petición se indica en la cabecera Content-Type, y esto es importante para que al procesarse la petición el backend sepa cómo procesar los datos de entrada.

En caso de que se utilice el formato XML, dado que es un metalenguaje que permite especificar distintos esquemas, es imprescindible que este incluya el esquema usado para indicar al backend como interpretar la entrada.

Si lo que queremos es adjuntar archivos, estos deben de ir codificados. Habitualmente se usa la codificación base64, aunque cualquier tipo de codificación podría ser válido siempre y cuando se indique en alguna cabecera como Content-Encoding el algoritmo de codificación. Recordemos que la codificación es un proceso reversible que consiste en traducir de un formato a otro, algoritmos de hashing como MD5 o SHA1 no servirían.

Formatos de respuesta

Para el formato de las respuestas existen una serie de estándares que nos permiten desarrollar clientes de una forma más sencilla. Veamos algunos de ellos.

JSON-API JSON-API es un formato documentado de respuestas para APIs. Explicarlo con detalle daría pie a un post entero dedicado a ello, por lo que solo comentaremos una serie de detalles. Suele componerse de una serie de top-level elements o elementos raíz, por ejemplo links, con toda la información relativa a la paginación en caso de estar devolviendo listas de recursos. Otro elemento imprescindible es data, que puede ser a su vez un objeto de tipo resource object o un array de este tipo de objetos (si la respuesta es una colección). Si la petición ha resultado fallida no contendrá ninguno de estos elementos, y en su lugar tendrá un elemento errors con los errores que se han producido. Recomiendo echar un vistazo a la especificación completa con ejemplos en la web oficial, se pueden encontrar los enlaces en la sección de Bibliografía o el enlace al inicio de esta sección.
HAL Este formato en realidad no ha llegado a pasar la fase de borrador o draft, por lo que se pueden encontrar implementaciones, pero no se garantiza su soporte o compatibilidad. En muchos aspectos es muy similar a JSON-API. Podría decirse que JSON-API usó de base JSON-HAL para definir su formato. De nuevo, recomiendo echar un vistazo a la especificación completa con ejemplos en el draft, se pueden encontrar los enlaces en la sección de Bibliografía o el enlace al inicio de esta sección.

Conclusión

Hemos dado un repaso a varias de las características principales de las APIs HTTP, es buen momento para dejarlo aquí y reflexionar sobre lo aprendido y observar nuestras propias APIs y pensar en cómo podemos mejorarlas.

Esta serie de posts seguirá abierta, en breve hablaremos de algunos tipos de APIs, como REST, RESTful, GraphQL… hablaremos de temas accesorios pero no por ello menos importantes, como autenticación, seguridad, serialización, documentación, versionado…

Esperamos que todo este conocimiento que hemos ido recopilando os sea de utilidad y sigáis leyendo el resto de la serie!

En próximos posts…

Bibliografia

Estrategias de migración: Strangler Fig Application y Anticorruption Layer

Miguel Ángel Sánchez Chordi — Thu, 29 Jul 2021 07:41:01 +0000

Estrategias de migración de legacy code: Strangler Fig Application y Anticorruption Layer

Ficus Estrangulador Australiano

Introducción

Si hay algo por lo que todos pasamos alguna vez, es por heredar y mantener un proyecto. Puede ser un proyecto antiguo de nuestra empresa, un proyecto que ha llegado de un cliente descontento con su anterior proveedor… etc. El mayor problema que esto supone es que habitualmente nos encontramos con proyectos desarrollados en tecnologías antiguas o desactualizadas, poco mantenidos, con un estilo o unas prácticas que no nos acaban de gustar (los programadores somos todos un poco especialitos en esto) y lo peor de todo: sin tests.

La palabra que siempre nos ronda a la cabeza cuando tratamos con estos proyectos heredados es “legacy code”, que como bien dijo Michael Feathers:

Legacy code is code without tests

Michael Feathers — Working effectively with legacy code

En realidad es mucho más que eso (que no es poco), ya que suelen ser proyectos poco o mal documentados (los tests son siempre la mejor documentación), con versiones de lenguajes, frameworks y librerías anticuadas u obsoletas, y muchas veces difíciles de volver a encarrilar, ya que se basan en prácticas poco amigables para con el testing o el refactoring. En pocas palabras: acumulan una gran deuda técnica.

Otro factor importante es que el proyecto suele ser la fuente de ingresos de una empresa que no puede permitirse el lujo de para máquinas de forma indefinida (como en su momento hiciera Evernote) para limpiar toda la deuda técnica y replantear los cimientos de su fuente de ingresos.

Si los grandes refactors muchas veces se descartan, la reescritura es algo que solo se suele plantear el equipo técnico (a veces desde un punto de vista poco empático de cara al cliente).

Otras veces el problema no es el tanto el código sino que debemos de construir un software sobre una fuente de datos que puede no encajar de la mejor forma con nuestro proyecto. O con un diseño pobre que puede ser mejorado, pero que requiere un gran esfuerzo y dedicación y que solo tras demostrar que el nuevo enfoque es mejor, el cliente estaría dispuesto a aceptar el cambio.

Ante estas situaciones ¿qué opciones tenemos?

En mi experiencia muchas veces se ha optado por mantener el proyecto legacy y o bien por presiones del equipo de desarrollo, por la dificultad para contratar a gente que se haga cargo del proyecto en el estado en que se encuentra o por problemas de crecimiento debidos al estado del proyecto, se ha optado por abordar una migración progresiva.

Esto no es otra cosa que empezar a desarrollar nuevas partes del proyecto sobre un stack moderno y con mejores prácticas, pero sin dejar de depender del antiguo proyecto. Estas migraciones pueden durar eternamente, pero suelen insuflar nueva vida a un proyecto que estaba agonizando, y con una buena planificación es posible dejar de depender del antiguo proyecto a medio plazo.

Me gustaría hoy hablar de dos estrategias de migraciones progresivas sobre los que me he apoyado cuando he tenido que abordar este tipo de tareas: Strangle Fig y Anticorruption Layer.

Strangler Fig Application (Ficus Estrangulador)

Este estrategia fue propuesta por Martin Fowler en 2004. Aunque inicialmente se llamó Strangler Application, posteriormente fue renombrado a StranglerFigApplication en 2009 para evitar la connotación negativa de la palabra Strangler (estrangulador):

bliki: StranglerFigApplication

Esta técnica de migración consiste en interponer una fachada entre el cliente y el sistema a migrar. De puertas para adentro, empezaremos a migrar progresivamente partes del proyecto legacy a el nuevo sistema, y será la fachada la que se encargará de redirigir el cliente al nuevo o al viejo sistema según sea necesario.

Migración progresiva de un proyecto legacy a un nuevo sistema

Esto nos va a permitir realizar una migración sin la presión de tener que “parar máquinas” y dejar el proyecto en stand-by, permitiéndonos priorizar la migración de las partes más críticas sin importar sus dependencias, ya que las podremos satisfacer contra el sistema legacy.

No todo son ventajas, por supuesto. El uso de esta estrategia puede incrementar los tiempos de respuesta mientras dure la migración, así como los costes de infraestructura, ya que al menos necesitaremos separar el sistema legacy del nuevo, además de tener una capa encargada de la distribución. Aún así, es preferible esto a dejar nuestro proyecto estancado.

Esta estrategia está siendo adoptada por frameworks como Symfony para facilitar las migraciones desde otros frameworks. Además, existen numerosos casos de éxito documentados que han seguido esta práctica.

Anticorruption Layer

La siguiente estrategia o patrón que vamos a ver es la Anticorruption Layer (abreviado como ACL) propuesta por Eric Evans en su libro Domain-Driven Design: Tackling complexity in the heart of software.

Básicamente, la ACL es una capa que se encargará de traducir entre el modelo de datos legacy y el nuevo modelo de datos. Es muy similar en misión al patrón adapter, del cual ya hablamos en su momento, pero aplicado a datos en este caso.

Pero no solo eso, sino que además, esta capa puede implementar también algunas comprobaciones de seguridad, devolver valores por defecto en caso de no existir en el sistema original, lanzar excepciones más específicas para casos de error o incluso implementar un circuit-breaker si el problema se debe a la disponibilidad del servicio.

Comunicación entre sistemas legacy y modernos a través de una ACL.

¿Cuándo usar Anticorruption Layer?

Podemos ver la respuesta en palabras de el propio Eric Evans:

If your application needs to deal with a database or another application whose model is undesirable or inapplicable to the model you want within your own application, use an Anticorruption Layer to translate to/from that model and yours.

Eric Evans — Domain-Driven Design: Tackling complexity in the heart of software

O en palabras de Vaughn Vernon, autor de Implementing Domain-Driven Design:

Even if you are able to avoid creating a Big Ball of Mud by employing DDD techniques, you may still need to integrate with one or more. If you must integrate with one or more, try to create an Anticorruption Layer against each legacy system in order to protect your own model from the cruft that would otherwise pollute your model with the incomprehensible morass.

Vaughn Vernon — Domain-Driven Design Distilled

Es decir, siempre que necesitamos que nuestro sistema hable con otro sistema cuyo modelo de datos no es el deseado, o incluso si estamos heredando una base de datos sobre la que construir un nuevo proyecto, podemos usar una ACL para traducir del viejo modelo al nuevo evitando que el legacy contamine nuestro proyecto.

Casos de uso de ACL

Esta técnica es ampliamente utilizada en arquitecturas de microservicios donde existen distintas versiones de las APIs de comunicación e incluso de los modelos de datos (recordemos que cada microservicio tiene su propia base de datos con su propio esquema).

Un problema que puede derivar de la práctica de la migración mediante StranglerFigApplication es que en ocasiones será necesario que exista comunicación entre el proyecto legacy y el nuevo, por lo que el uso de esta técnica combinada con la anterior es más que recomendable.

Otro caso de uso que para el que he aplicado personalmente esta estrategia ha sido para lidiar con bases de datos NoSQL que tienen en una misma colección documentos con distinto esquema. Es especialmente útil el uso de una ACL que homogeneice el esquema de todos los documentos para que encajen adecuadamente con los objetos del dominio.

Conclusión

Aunque puede resultar tentador proponer una reescritura entera de un proyecto desfasado, es importante valorar nuestras opciones antes. No siempre va a ser posible abordar este tipo de proyectos, pero debemos de conocer qué otras alternativas tenemos.

Esto es solo una muestra de un par de estrategias que personalmente me han resultado útiles en el pasado, pero no son las únicas, en un futuro hablaremos de otras.

Saludos!

Microservicios

Miguel Ángel Sánchez Chordi — Mon, 06 Jul 2020 07:01:01 +0000

Foto por Vivek Doshi

Seguro que en los últimos años has oído hablar del concepto de microservicios, puede que hayas profundizado en el tema, o incluso llegado a trabajar en algún proyecto en base a microservicios, pero para la mayoría sigue siendo un tema del que muchos hablan pero pocos se han pasado por las manos.

Como cualquier otra tecnología que cobra relevancia, tiene sus defensores y sus detractores, cada uno con su línea de argumentación (totalmente válida). El caso es que existe y que no sea una solución para nuestro proyecto o nuestros proyectos del día a día, no quiere decir que no tenga su caso de uso.

En este post vamos a intentar explicar en líneas generales en qué consiste la arquitectura de microservicios, sus pros, sus contras, problemas conocidos y distintas formas de comunicación. No pretende ser una guía exhaustiva, por lo que no voy a tratar en profundidad demasiados conceptos.

Vamos allá!

Introducción

Habitualmente abreviado como MSA (Micro Services Architecture), es una variación de SOA o Arquitectura Orientada a Servicios (Service Oriented Architecture), y aunque parezca algo totalmente nuevo y actual, se viene hablando, escribiendo y poniendo en práctica desde 1996 (Gartner).

Aunque no sería hasta 2005 cuando Peter Rodgers acuñaría el termino Micro-Web Services durante una presentación en la Web Services Edge conference.

Desde entonces, muchos han sido los que han hablado o escrito sobre el tema:

Y una lista casi infinita de expertos reconocidos. Pero ¿en qué consiste una arquitectura de microservicios? ¿Qué características tiene?

Básicamente, una arquitectura de microservicios consiste en construir una aplicación como un conjunto de pequeños servicios, independientes entre ellos tanto a nivel código como a nivel de infraestructura y que se comunican entre ellos con mecanismos ligeros (baja latencia).

Cada servicio:

Gestiona una parte de negocio única y exclusivamente
Debe poder desplegarse y escalarse de forma independiente sin tener esto efecto sobre el resto de servicios
Puede estar escrito con el lenguaje que mejor se adapte a su propósito, así como usar las tecnologías más convenientes (por ejemplo, bases de datos no-SQL cuando el resto de microservicios usan SQL).

Ventajas

Teniendo en cuenta la anterior descripción, no son pocas las ventajas que nos aporta esta arquitectura:

Desarrollo modular: Cada servicio tiene una única meta, esto hace que su responsabilidad quede claramente acotada y su equipo de desarrollo puede especializarse en ello, sin interferencias de cambios en otros aspectos del negocio. Es una especie de SRP a nivel módulo.
Independencia de infraestructura: Los módulos pueden y deben seguir su propio ciclo de vida, desplegarse nuevas versiones cuando sea necesario (sin conflictos o necesidad de esperar a otros). Asimismo, cada microservicio es responsable de su propia infraestructura, incluyendo su propia base de datos.
Escalado independiente: En un escenario donde tenemos un monolito y de repente tenemos un incremento bestial de un tipo de peticiones en concreto (registros por ejemplo, debido a una agresiva campaña de marketing), nuestra única solución va a ser escalar todo el proyecto a la vez, bien sea de forma vertical (añadiendo o mejorando el hardware) o si hemos sido suficientemente prudentes de tener separada la base de datos y otros servicios en otras maquinas, un escalado horizontal (aumentar el número de servers con servidores web y poner un balanceador de carga al frente). En un sistema basado en microservicios simplemente necesitas escalar de forma horizontal el número de servers que sirven el microservicio de usuarios.
Optimización del esquema de datos: La independencia de infraestructura, permite que en nuestros modelos de datos guardemos únicamente lo imprescindible para lograr nuestro objetivo. Si por ejemplo disponemos de un microservicio de Posts y uno de Users, podemos guardar en la base de datos de Users tan solo un contador con el número de posts (si solo necesitamos ese dato), y en la base de datos de Posts nos podemos permitir almacenar solamente el id, nombre y apellidos de cada User, ya que no vamos a necesitar nada más en nuestras vistas. Resultado: prácticamente resolvemos todas las consultas a base de datos sin hacer JOIN, consultas directas a índice.
Independencia de stack: Pueden desarrollarse con el lenguaje que mejor encaje en el problema a resolver, sin tener en cuenta en cuál (o cuáles) se ha desarrollado el resto de microservicios.

Inconvenientes

Desarrollo más complejo: A medida que el número de microservicios crece, levantar un entorno de desarrollo para cada equipo es más complicado. Además, el debug de estas arquitecturas es bastante más complejo que el de un monolito.
Versionado de microservicios: La independencia de cada microservicio puede llegar a ser un caos si no se versiona correctamente, ya que puede haber otros microservicios dependientes de uno que se acaba de actualizar que aún no sea compatible con los nuevos cambios, y eso nos obliga a mantener distintas versiones de cada microservicio en marcha que garantice el funcionamiento de todo el enjambre.
Información duplicada: Gran parte de la información estará duplicada en las distintas bases de datos de los distintos microservicios, ya que cada uno debe de ser independiente a nivel datos.
Consistencia eventual: Las actualizaciones pueden ser un quebradero de cabeza, por ejemplo, si el usuario decide actualizar su nombre y apellidos, ya que en el microservicio de Posts deberemos de actualizar este dato en todos sus posts. Esto puede dar lugar a problemas de consistencia eventual debido a la latencia entre comunicaciones (el dato se ha actualizado en algunos servicios, pero no en otros).

Arquitectura de microservicios

Como convención, vamos a hablar de diseño de “microarquitectura” cuando nos refiramos a la arquitectura interna de cada microservicio, y diseño de “macroarquitectura” cuando nos refiramos a la arquitectura que los une.

Veamos a continuación algunos detalles a cada nivel.

Detalles de diseño a nivel microarquitectura

La construcción interna de los microservicios no está atada a ningun contrato, ya que como hemos repetido varias veces, cada microservicio es independiente de los demás a nivel infraestructura y a nivel stack tecnológico, pero lo que si es cierto es que hay una serie de técnicas y patrones de diseño que favorecen mucho el mantenimiento de estos, y que al mismo tiempo simplificará en algunos casos la comunicación entre ellos.

Arquitectura Hexagonal

Hemos hablado de arquitectura hexagonal en otras ocasiones, aunque quizá sea interesante dedicar un post entero a tratar el tema, pero para no desviar la atención del tema principal, haré un pequeño resumen.

He usado círculos para hablar de arquitectura hexagonal? He usado círculos para hablar de arquitectura hexagonal.

La arquitectura hexagonal o también llamada arquitectura limpia (de Clean Architecture) es una forma de diseñar software por capas haciendo un uso del también conocido patrón adapter. La arquitectura por capas favorece la cambiabilidad de las dependencias de terceros sin afectar a las capas dependientes (inversión de dependencias).

Tenemos tres capas:

Dominio
Aplicación
Infraestructura

Cada una de las capas solo puede conocer a las más internas, es decir, siempre de fuera hacia adentro. Por lo tanto, Infraestructura conoce Aplicación y Dominio, Aplicación conoce a Dominio, y Dominio solo se conoce a sí misma.

Y qué es cada capa?

Dominio contiene únicamente el código relativo a entidades, value objects, interfaces de servicios… básicamente los contratos que deberá de cumplir el código. En otros contextos lo podemos relacionar con el core de una aplicación.
Infraestructura son las implementaciones de los contratos definidos en Dominio. Por ejemplo, si tenemos una interfaz del servicio de repositorio UserRepository, en infraestructura podemos tener distintas implementaciones del mismo, por ejemplo RedisUserRepository_,_ DoctrineUserRepository_,_ o ElasticSearchUserRepository por citar algunos ejemplos.
Aplicación contiene la implementación de casos de uso de nuestra aplicación, como por ejemplo Registrar un Usuario o Publicar un Post. Esta capa solo conoce los contratos definidos en Dominio con lo que cualquier implementación de Infraestructura deberá de ser inyectada como una interfaz de Dominio. Así, para por ejemplo Registrar un usuario necesitaríamos un UserRepository, no importa qué implementación, ya que cualquiera de ellas cumplirá con el contrato y sabremos de qué métodos disponemos.

Viéndolo de forma gráfica quedaría algo así (fíjate en que cada color que representa la capa a la que pertenece):

Esto es inversión de dependencias en estado puro, y es lo que hace que nuestro código sea limpio, cambiable, testeable y fácilmente mantenible.

CQRS

Sobre CQRS también podríamos dedicar posts enteros a tratar el tema, pero vamos a tratar de resumirlo de forma simple.

Bertrand Meyer definió originalmente el concepto de Separación de consultas y comandos (CQS) en el libro Object-Oriented Software Construction. La idea básica es que las operaciones de un sistema se pueden dividir en dos categorías claramente diferenciadas:

Consultas (Queries). Devuelven un resultado sin cambiar el estado del sistema y no tienen efectos secundarios (side effects).
Comandos (Command). Cambian el estado de un sistema (y pueden tener side effects).

Posteriormente Greg Young introdujo el concepto Segregación de responsabilidad de consultas y comandos (CQRS). Se basa en el principio CQS, aunque con más detalles, por ejemplo, con CQRS se puede tener una base de datos para operaciones de lectura (queries) distinta de la de operaciones de escritura (commands), o distintos modelos de datos para las respuestas de las queries o las peticiones de los commands.

Pero una de las mayores diferencias es la posibilidad de realizar operaciones asíncronas mediante el envío de commands a través de un bus de comandos asíncrono, de forma que no necesitemos esperar a la respuesta de la base de datos para seguir con el hilo de la ejecución.

En resumen a nuestra infraestructura vamos a incorporar una serie de nuevos elementos:

Commands: Clases que encapsulan operaciones de escritura. Por ejemplo, en el caso de Registrar un usuario este command incluiría el email y la contraseña del usuario registrado.
Queries: Clases que encapsulan operaciones de lectura. Por ejemplo, en el caso de uso Obtener un post la query incluiría el id del post a obtener.
Handlers: Tendremos QueryHandlers y CommandHandlers, los QueryHandlers devuelven el contenido deseado, los CommandHandlers, debido a que su ejecución puede ser asíncrona, no devuelven nada.
Buses: Tendremos QueryBus y CommandBus, y el CommandBus puede ser síncrono (esperamos a la operación de escritura) o asíncrono (no esperamos a la operación de escritura). Básicamente son colas donde metemos las queries y los commands para que se ejecuten.

Veamos gráficamente como quedaría el ejemplo anterior (fíjate en que cada color que representa la capa a la que pertenece):

Ahora el controlador “encola” el comando en un bus que puede ser síncrono o asíncrono, y esta petición es resuelta por el manejador (handler) asociado

Este bus de asíncrono será la base de lo que más adelante veremos como comunicación basada en eventos.

Detalles de diseño a nivel macroarquitectura

Ahora que tenemos claro como desarrollar nuestros microservicios nos enfrentamos al reto de hacer que hablen entre ellos, que se comuniquen.

Cuando teníamos un monolito esto no implicaba mayor problema, ya que todo quedaba en casa:

Esquema de arquitectura monolítica

Todas las peticiones apuntan al mismo sitio, solo hay una conexión a una base de datos y esa base de datos es la única fuente de datos de toda la plataforma.

Como ya hemos comentado antes, en el caso de que, por ejemplo, la creación de posts se incrementara de forma inesperada, la única base de datos del nuestro sitio se saturaría por las escrituras que está recibiendo por parte de usuarios publicando contenido. Esto por supuesto afectaría al endpoint de obtener usuarios, aumentando los tiempos de respuestas e incluso obteniendo timeouts.

En el caso de tener microservicios la comunicación es más compleja, pero podemos evitar el problema de que un pico de peticiones de un tipo en concreto nos tumbe el sitio entero.

Vamos a ver a continuación distintas formas de comunicación en microservicios.

Formas de comunicación

Microlitos sin infraestructura

Un caso muy común cuando se empieza con a migrar una arquitectura monolítica a una basada en microservicios es romper el monolito en otros más pequeños que popularmente reciben el nombre de microlitos.

El esquema que vamos a ver a continuación sería el de Microlitos sin infraestructura: aunque hemos separado a nivel software el código en distintos servicios, seguimos compartiendo la infraestructura común (en este caso la base de datos).

Microlitos sin infraestructura

¿Se puede considerar este esquema como una arquitectura de microservicios? A duras penas podemos decir que cumple con todas las condiciones para ser un esquema de microservicios:

✅ Cada servicio gestiona una parte de negocio única y exclusivamente.
❌ No puede desplegarse y escalarse de forma independiente sin tener esto efecto sobre el resto de servicios. Si por ejemplo desplegamos una nueva versión del microservicio de usuarios que aplica cambios a la base de datos, puede afectar al microservicio de posts.
❌ No son independientes, una sobrecarga de peticiones en el microservicio de posts seguiría perjudicando al microservicio de usuarios.
❌ No utilizan mecanismos de comunicación de baja latencia para comunicarse, de hecho, no se comunican, la base de datos es el único intermediario, toda la información obtenido por cada microservicio sale del mismo sitio.

Es un punto de partida, pero no podemos quedarnos aquí indefinidamente, debemos evolucionar nuestra arquitectura.

Microlitos vía HTTP

Una segunda parada en el camino hacia los microservicios independientes es hacer que nuestros microlitos es dejar de compartir la base de datos.

Puesto que el microlito de usuarios solo mantiene datos relacionados con los usuarios, es posible que surja la necesidad de obtener alguna información relacionada con los posts propiedad de ese usuario, por ejemplo, saber el número de posts que ha publicado.

No podemos guardar ese dato, no nos corresponde. Cada microlito expone una API por lo que parece una buena opción que nuestros microlitos se comuniquen vía HTTP para obtener la información necesaria.

El color azul del campo “total_posts” denota que es un dato que proviene de la base de datos de posts.

Ahora que nuestros microlitos tienen cada uno su propia base de datos no nos preocupa que una sobrecarga en el número de peticiones de crear posts bloqueen el microlito de usuarios… o sí debería preocuparnos?

Aunque somos independientes a nivel código e infraestructura, una eventual caída de otro microlito podría dejarnos fuera de juego también, ya que si el número de peticiones POST aumenta en el microlito de posts, esto afectará también a las peticiones GET que hacemos desde el microlito de usuarios, la base de datos puede seguir bloqueándose y por tanto bloquearnos.

Y cómo solucionamos esto? Circuit Breaker al rescate!

Circuit Breaker

Circuit Breaker es un patrón popularizado por Michael T. Nygard en el libro Release It!, básicamente se basa en el comportamiento que tiene un fusible en un circuito eléctrico: cuando algo se sobrecarga actúa como barrera abriendo el circuito (en electrónica un circuito eléctrico es aquel que esta discontinuado, y por lo tanto no funciona). Cómo se aplicaría esto a microservicios? Miremos el siguiente esquema:

En el la línea de eventos podemos ver como el cliente solicita a un servicio un dato, pero este tiene un intermediario, el circuit breaker. Este circuit breaker esta configurado para tener un umbral de error de 2 reintentos, al segundo fallo abrirá el circuito y dejará de haber comunicación entre cliente y servicio.

Tal y como muestra el gráfico, tras dos errores, la comunicación es cortada y aquí podemos optar por técnicas como mostrar un valor por defecto para el dato consultado (por ejemplo, en este caso, total_posts: 0 sería una solución de compromiso).

Esta apertura del circuito permite al servicio recuperarse de la avalancha de tráfico que le ha hecho caer. Obviamente pasado un tiempo el circuito vuelve a cerrarse y vuelve a aceptar peticiones, pero no voy a entrar en detalle en cómo se hace esto.

Otro dato importante, aunque en el esquema solo se vea un servicio, en una arquitectura de microservicios cloud lo habitual es tener más de un servicio detrás del circuit breaker:

Eventos de dominio

La última forma de comunicación que vamos a ver es a través de eventos de dominio, una forma que desde mi punto de vista tiene una serie de ventajas respecto a escalabilidad bastante interesante.

Partimos del concepto de “dominio” que ya hemos comentado antes cuando hablábamos de arquitectura hexagonal a nivel de diseño de microarquitectura. Como su nombre indica, un evento de dominio representa un suceso que ha ocurrido en nuestro sistema, relacionado con el dominio de nuestra aplicación, nuestro core, nuestra lógica de negocio.

Algunas características de los eventos de dominio:

Deben de ser serializables en un formato que permita interoperabilidad. Recordemos que nuestros microservicios son tecnológicamente independientes, si emitimos un evento serializado con el formato nativo de nuestro lenguaje (PHP, JAVA, Python…) difícilmente va a ser entendible para otros microservicios que usen un stack diferente. Formatos como JSON, XML o YAML son ejemplos de formatos que permiten la interoperabilidad.
Deben de ser identificables. Cada evento debe de ser capaz de ser buscado por un identificador único, con lo que debemos asegurarnos de utilizar un sistema de identificación que no lleve a error. Formatos autonuméricos incrementales suelen ser una mala idea: vamos a tener muchos microservicios emitiendo eventos, ¿cómo llevamos la cuenta del autoincremento? Sistemas como los UUID dan garantías de unicidad y también son un formato de identificación interoperable.
La fecha es importante. Tan importante como su identificación es saber cuándo sucedió. En el caso de eventos es importante poder ordenarlos de forma unívoca (recordemos que no podemos usar identificadores autonuméricos), por lo que la fecha es muy importante. Ahora bien, tenemos que tener en cuenta que el formato de fecha y hora debe de ser interoperable entre distintos stack, por lo que es importante usar formatos como ISO-8601 o POSIX Timestamp. Algo de vital importancia también es usar como zona horaria UTC, ya que podemos tener microservicios operando en distintas zonas horarias y eso puede causar un caos informativo. A través de UTC podemos transformar la fecha a cualquier franja horaria sin mayores complicaciones.
Han ocurrido ya (pasado). Esto es importante tenerlo en cuenta a la hora de definir una estrategia de nombrado para nuestros eventos de dominio, esto es importante para poder distinguir un evento de dominio (verbos en pasado) de acciones o casos de uso (verbos en infinitivo).
Formato estandarizado. Además del nombre del evento, también el contenido del evento debe de seguir una estandarización. En el cuerpo de un evento debemos de encontrar la información necesaria para manejar la situación, ya que la respuesta habitual a un evento son los efectos secundarios o side-effects, una respuesta del sistema ante tal evento. Que todos los eventos tengan una estructura similar simplifica el desarrollo de listeners para nuestros eventos de dominio.
No necesariamente todo evento debe de disparar efectos secundarios. No solo debemos de lanzar eventos cuando deseemos que ocurra un efecto secundario, en una arquitectura orientada a eventos todo suceso debe de quedar registrado, aunque no haya ningún efecto secundario esperando a que suceda un evento. Esto además nos permite llevar un registro (da igual la forma: base de datos, archivos de log…) de todo cuanto sucede en nuestro sistema.

Algunos ejemplos de serializado de un evento de dominio:

Contenido basado en primitivas

Contenido basado en objetos

Como se puede apreciar en ambos ejemplos, la información relativa al evento se puede expresar de múltiples maneras, lo importante es conservar un esqueleto común a todos los eventos y que el contenido propio de cada evento se adapte a las necesidades de cada caso.

Esqueleto común

Me gustaría dar una opinión personal al respecto del contenido de los eventos, y es que es mejor añadir información de más que de menos. Hay que intentar adelantarse en la medida de lo posible a las futuras necesidades de los manejadores de eventos, ya que es probable que si actualizamos en algún momento el cuerpo de nuestros eventos, en el momento de hacer el despliegue haya todavía en cola muchos eventos con el anterior contenido, y eso puede darnos pie a errores en el manejo de los eventos.

Comunicación mediante eventos de dominio

Ahora que estamos ya familiarizados con el concepto de eventos de dominio, vamos a ver cómo quedaría nuestra macroarquitectura de comunicación en el siguiente gráfico:

Hemos incorporado un nuevo elemento a nuestra arquitectura de comunicación: el bus de eventos.

Los microservicios ya no se comunican directamente entre ellos, sino que lo hacen a través de un nuevo elemento arquitectural que implementa el patrón Pub/Sub (Publisher/Subscriber). No hemos hablado nunca en el blog sobre este patrón así que vamos a dar unas pinceladas sobre cómo funciona para meternos en contexto.

Patrón Pub/Sub

El patrón Pub/Sub ofrece una forma eficaz de comunicación asíncrona desacoplando a los emisores de mensajes de sus receptores, evitando de esta manera que el emisor quede bloqueado a la espera de una respuesta.

Hay 3 actores principales en este patrón:

Emisor (Publisher): Es quien lanza un evento, quien decide comunicar que algo ha sucedido, permitiendo a quien esté interesado en reaccionar de alguna manera hacerlo, pero sin depender de la respuesta de estos.
Bus de Eventos (Message Broker): Es el canal de comunicación donde el emisor publica sus mensajes (eventos) y es este mismo sistema el encargado de notificar a los suscriptores de que se ha producido el evento que están interesados en manejar.
Subscriptor (Subscriber): Es el cliente, el receptor de el mensaje. No necesariamente debe de haber un único subscriptor para cada mensaje, ni un mismos subscriptor debe de estar esperando un único tipo de mensajes.

Para garantizar la asincronía el bus de eventos suele delegar su capa de transporte sobre un servicio de colas de mensajería como puede ser Redis, RabbitMQ, Apache Kafka, IronMQ, AmazonSQS, MQTT… que disponen de muchas funcionalidades extra que permiten manejar de forma optima todos los puntos oscuros de este patrón, como los eventos desordenados o los duplicados.

Ventajas

Añade una capa de indirección entre productor de mensajes y consumidores. Esto incluso nos permite tener productores implementados en un lenguaje diferente al que ha sido implementado el consumidor (y viceversa). Este desacople es una de las virtudes por las que la arquitectura de microservicios es elegida.
Se evitan bloqueos a la hora de esperar una respuesta por parte del consumidor. Si es necesaria una respuesta, la recibiremos por el mismo Bus en el que hemos publicado nosotros el mensaje, y podremos subscribirnos a ella, mientras tanto, podemos seguir con nuestro trabajo.

Inconvenientes

Añade una capa de indirección entre productor de mensajes y consumidores. La misma virtud puede llegar a ser un defecto en determinados escenarios. Tenemos que estar seguros de no necesitar una respuesta inmediata a nuestro evento. El debug en estos casos también se vuelve mucho más complejo.
Las colas pueden saturarse y esto puede acabar con efectos secundarios poco deseados, como mensajes duplicados o mensajes que llegan desordenados. Mas adelante profundizaremos en esto.

Por lo tanto, la comunicación de nuestros microservicios ahora queda delegada a un nuevo elemento con gran capacidad de escalado, por lo que no podemos llegar a saturarlos por llamadas internas entre ellos como en el caso de comunicación por HTTP.

Consistencia Eventual

Antes hemos introducido el concepto de consistencia eventual sin entrar en mucho detalle, para hacernos una idea y sin entrar en mucho detalle, podríamos definir la consistencia eventual como el hecho de que la información en todos nuestros microservicios puede no estar perfectamente actualizada en todo momento (no es consistente), pero que tarde o temprano acabará estándolo.

Por qué sucede esto? Es fácil suponer que en un sistema formado por eventos que fuerza la actualización de los datos en distintos microservicios, todo esto no ocurre de forma simultánea ni cohesionada, cada microservicios puede tener sus tiempos, su carga de trabajo, su latencia, sus tiempos de ejecución…

Estamos en un ecosistema muy diverso a muchos niveles: podemos tener múltiples stacks tecnológicos a nivel de microarquitectura, con lenguajes más o menos rápidos, con distintas cargas de trabajo, probablemente con sistemas de bases de datos diferentes que puede que estén optimizadas para lectura y no para escritura o al revés… Así que tenemos que convivir con el hecho de que no todo estará siempre actualizado.

¿Cómo evitar la consistencia eventual?

Ni puedo ni me atrevo a profundizar en este post sobre este tema, ya que daría para una nueva colección de posts, pero sí, existen formas de convivir con la consistencia eventual, por ejemplo con las transacciones distribuidas aunque también tengan sus puntos oscuros .

Hay otras corrientes de pensamiento que afirman que si necesitas que varios sistemas sean siempre consistentes, quizá deberían ser un único sistema.

Sistemas de colas

El uso de sistemas de colas como RabbitMQ, MQTT, Amazon SQS… y otros proveedores es uno de los puntos fuertes de la comunicación basada en eventos de dominio.

Estos sistemas también llamados brokers de mensajería nos permiten comunicar nuestros eventos en una amplia variedad de formas, por mi parte puedo hablar más específicamente de RabbitMQ que es el que más he usado y que me parece muy potente y versátil.

En todo sistema de colas tenemos una serie de actores:

Productores: Son quienes emiten el mensaje
Exchange/Broker: Es el sistema encargado de distribuir el mensaje en las colas apropiadas, pueden tener distintas formas de distribución: topic, fanout o direct.
Colas: Son los recipientes de los mensajes, a las colas se conectan los consumidores para obtener los mensajes.
Consumidores: Son quienes se conectan a las colas en busca de mensajes que procesar. Si procesan el mensaje de forma correcta devuelven a la cola un código ACK indicando que el procesamiento ha sido correcto, en caso contrario, responderán a la cola con un NACK, provocando que el mensaje sea reencolado para volver a ser consumido posteriormente.

Como antes decía, el broker puede estar configurado para distribuir los mensajes de varias maneras, veamos en el caso de RabbitMQ como funcionan estas tres formas:

Fanout: Los mensajes recibidos se envían a todas las colas sin excepción.

Exchange en modo fanout, el mensaje llega a todas las colas.

Direct: El mensaje se publica solo a las colas suscritas a ese tipo de mensaje. El tipo suele ser el nombre del evento producido.

Exchange en modo direct, solo aquellas colas cuya binding key coincida con el mensaje lo van a poder recibir.

Topic: Es como direct , solo que permite el uso de expresiones regulares, por ejemplo, en direct la clave o binding key de una cola podría ser post.created_,_ en topic la binding key podría ser post.* y estaría suscrito a cualquier mensaje que empiece por post.

Exchange en modo topic. Si el nombre del tipo de mensaje pasa por la regex de la binding key, la cola recibe el mensaje.

Todos estos modos de operar de las colas nos permiten una amplia flexibilidad, podemos usar por ejemplo el modo topic y crear una cola suscrita a los eventos de tipo *.log y añadir un consumidor que se encarga de hacer un logging de todos los eventos producidos.

Otras ventajas de estos sistemas es su fácil escalabilidad, al tratarse de servicios de infraestructura (como las bases de datos o las cachés), podemos tener tantas instancias como necesite nuestro sistema y crecer de forma indefinida.

Gestión de errores de las colas

Básicamente hay dos errores que se pueden producir al usar eventos de dominio con sistemas de colas, y son los eventos desordenados, y nada lo ejemplifica mejor que este twitt de Mathias Verraes:

// Detect dark theme var iframe = document.getElementById('tweet-632260618599403520-835'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=632260618599403520&theme=dark" }

Algo que podríamos traducir como:

Hay dos problemas difíciles en sistemas distribuidos:

Recibir el evento sólo una vez

El orden de los eventos

Recibir el evento sólo una vez

Eventos desordenados y Dead letter queues

En ocasiones el orden es importante.

Hay sistemas de colas que no garantizan el orden de entrega, de hecho, es casi lo más habitual.

Esto puede no ser un problema por sí mismo, salvo que los eventos desordenados sean dependientes entre sí, por ejemplo notificar a un usuario de que su autor favorito ha escrito un nuevo post antes de el evento de que el post ha sido creado haya sido recibido. Esto podría provocar un error de consistencia eventual al tratar de buscar el post si aún no existe en la base de datos.

Una forma de gestionar estos errores es el uso de dead-lettering. Esto básicamente consiste en llevar una cuenta de las veces que un mensaje ha sido devuelto con un NACK, si supera cierto umbral, este mensaje es mandado a una cola de dead-lettering, donde un consumidor especial podrá procesarlo de la manera adecuada:

Elimándolo
Notificando a alguien del suceso
…

Eventos duplicados

Cuando nuestra infraestructura de colas crece y aumentan el número de máquinas que la controlan, existe la posibilidad de que un mismo evento se envíe dos veces o más (por distintas máquinas). Los sistemas de colas distribuidas necesitan mantener los mensajes en un espacio compartido, que bien puede ser memoria o disco duro. En ambos casos se produce una latencia que puede provocar el envío de un mensaje de forma duplicada:

La máquina A envía el mensaje 815c5068-72e6-40ad-96f1-b0ec7cd57d73
El consumidor A empieza el procesado del mensaje 815c5068-72e6-40ad-96f1-b0ec7cd57d73
La máquina B envía el mensaje 815c5068-72e6-40ad-96f1-b0ec7cd57d73
El consumidor A envía un ACK a la máquina A
El consumidor B empieza el procesado del mensaje 815c5068-72e6-40ad-96f1-b0ec7cd57d73
La máquina A elimina el mensaje 815c5068-72e6-40ad-96f1-b0ec7cd57d73

Entre el paso 1 y 6 el mensaje sigue disponible para ser enviado a consumidores, por lo que si el procesado es largo puede provocar que se procese más de una vez.

En realidad los sistemas de colas disponen de mecanismos para evitar estos problemas (sistemas de lock que impiden que se sirva dos veces el mismo mensaje), pero tienen un alto coste en el rendimiento de las colas y suele preferirse prescindir de él y manejar los posibles errores de duplicidades.

¿Cómo gestionamos estos errores?

De nuevo muy a grosso modo vamos a ver unas posibles soluciones:

Dead Lettering. Si el mensaje no puede ser procesado dos veces, dará un error y el consumidor devolverá un NACK, si esto se produce las veces suficientes, acabará en Dead Lettering y será procesado de otra manera.
Registro de mensajes ejecutados. Podemos llevar un registro con el id de todos los mensajes ejecutados, y antes de ejecutar un nuevo mensaje, comprobar si ya ha sido previamente ejecutado. Esto en un entorno de muchos consumidores para un mismo mensaje, puede seguir dando problemas, ya que mientras se registra el mensaje como procesado podría volverse a procesar.
Idempotencia . Este concepto nos garantiza que la misma ejecución de un evento repetidas veces producirá el mismo resultado. Por ejemplo, en el caso de un evento de post.created intentaremos volver a insertar ese registro en nuestra base de datos, si obtenemos un error porque el registro ya existe, simplemente ignoraremos el error y devolveremos un ACK a la cola. Otra opción sería antes de intentar insertar el registro comprobar si existe previamente.

Conclusiones

Las arquitecturas de microservicios son complejas, pero resuelven muchos problemas de escalabilidad y crecimiento allá donde es necesario.

Probablemente si no trabajamos en grandes empresas con tráfico masivo y picos que puedan hacer peligrar la disponibilidad del servicio, jamás nos veremos ante un proyecto que requiera de su uso.

Pero no por ello es una solución innecesariamente complicada o basada en la sobreingeniería, solo lo será si intentamos matar moscas a cañonazos y decidimos implementar esta arquitectura por ser un poco más mainstream o porque es el concepto de moda.

Quizá se hable más ahora que hace 20 años de microservicios porque el número de grandes empresas con estas necesidades ha crecido y ha popularizado el termino, pero eso no lo convierte en un martillo de oro.

Espero que os haya gustado este post, aunque se ha quedado bastante más largo de lo habitual ;)

Saludos y hasta la próxima!