¿Qué es el middleware? Definición y ejemplos de casos de uso

Middleware es un término de uso común en el desarrollo web. Puede significar muchas cosas según el contexto, lo que hace que el término sea un poco confuso.

En este artículo, comenzaremos definiendo el término y luego continuaremos con una discusión sobre algunos casos de uso diferentes.

Después de leer este artículo, podrá involucrarse más en conversaciones técnicas y arquitectónicas con sus compañeros. También será más capaz en términos de diseñar API y flujos de datos seguros y confiables.

Definición de middleware

Middleware es un software que actúa como intermediario entre dos aplicaciones o servicios para facilitar su comunicación.

Puede pensar en él como un proxy que puede actuar como un acumulador de datos, traductor o simplemente un proxy que reenvía solicitudes.

Casos de uso común para middleware

1) traductor

Hay muchos formatos de intercambio de datos, como JSON, XML y Protobuf. Aunque usamos principalmente JSON hoy en día, cada uno de ellos tiene sus propios casos de uso.

Por ejemplo, se sabe que los Protobuffers son más eficaces que JSON, pero no son legibles por humanos. Por lo tanto, es posible que esté usando Protobuffers para servicios internos y puede usar JSON cuando el consumidor de API es un navegador.

También puede consultar mi artículo sobre Protobuffers si está interesado en aprender más sobre ellos.

Ahora digamos que necesitamos estos dos servicios, que hablan protocolos diferentes, para comunicarse entre sí.

Podemos crear un middleware que haga uso de una biblioteca de conversión de datos y traduzca las solicitudes a un formato que el servicio receptor pueda entender.

2) Acumulación-duplicación de datos

La arquitectura de microservicio es un patrón arquitectónico popular que se aplica comúnmente en aplicaciones modernas.

Si no está familiarizado con la arquitectura de microservicios, básicamente significa que su aplicación consta de muchas aplicaciones o servicios pequeños que son independientes entre sí y operan juntos comunicándose a través de Internet.

Por ejemplo, en un proyecto de comercio electrónico, puede tener un microservicio para almacenar y recuperar productos, otro microservicio para buscar y otro para autenticar y almacenar usuarios. Y cada uno tiene su propia base de datos.

Ahora digamos que queremos implementar nuestra búsqueda de manera que busque tanto usuarios como productos.

Si esta fuera una aplicación monolítica, simplemente podríamos escribir una consulta para buscar en cada tabla y unir los resultados. Pero ahora nuestras bases de datos se ejecutan en diferentes servidores.

Este problema tiene múltiples soluciones y veremos dos de ellas.

Acumulando datos

Podemos usar un middleware para enviar solicitudes a ambos servidores y pedirles que busquen en sus bases de datos nombres de usuario y productos que coincidan con la palabra buscada.

Luego, podemos acumular los resultados de ambos servidores y devolverlos al cliente. Tenga en cuenta que la cantidad de solicitudes aumenta linealmente a medida que aumentamos la cantidad de servidores (y también necesitamos fusionar esos datos).

Duplicar datos

Podemos almacenar datos duplicados en nuestro servidor de búsqueda para que pueda buscarlos directamente en lugar de solicitarlos a los servidores de productos y usuarios. Esto es menos eficiente en términos de memoria pero mucho más rápido, y la velocidad es fundamental para los servicios de búsqueda.

Si las tablas que necesitamos son Producto y Usuario, también podemos crear esas tablas en nuestro servidor de búsqueda. Luego, siempre que guardemos un nuevo usuario en nuestra base de datos de usuarios, también guardaremos una copia en el servidor de búsqueda.

Tenemos un par de opciones: primero, podemos llamar a los métodos de guardado del servidor de búsqueda desde los métodos de guardado de los servidores de Usuario y Producto para duplicar los datos. O podemos crear un middleware para guardar, que hará lo siguiente:

  • Siempre que llegue una solicitud de guardado, llame al servidor de Producto / Usuario y al servidor de búsqueda.
  • Si el primer guardado falla, no llame al guardado en otro (esto mantiene las bases de datos consistentes).

Veamos los diagramas de diseño sin y con middleware. Primero, así es como se ve sin:

Se ve feo, ¿verdad? De hecho, es feo y hará que su código sea más complicado y estrechamente acoplado.

Aquí está la misma solución con un middleware:

En este escenario, el lado del cliente simplemente llama al middleware para guardar un producto o usuario y se encarga del resto.

No hay ningún código relacionado con la duplicación de datos en los servidores del Producto o del Usuario o en el lado del cliente. Middleware se encarga de esas cosas.

3) Seguridad API

Para cualquier código del lado del cliente frontal, podemos ver las solicitudes salientes, ya sea en la consola del navegador o mediante un proxy.

Hablamos de un servidor de usuarios que se encarga del inicio de sesión y el registro. Si nuestro código de interfaz envía directamente las solicitudes a ese servidor, se expone la dirección de nuestro servidor de autenticación. Después de conocer la dirección IP de nuestro backend, los atacantes pueden usar herramientas para encontrar nuestros puntos finales y escanear nuestro servidor en busca de vulnerabilidades.

Podemos usar middleware como proxy para ocultar la URL de nuestro servidor de autenticación. Nuestro front-end se comunica con middleware y enviará la solicitud al servidor de autenticación y devolverá la respuesta.

Este enfoque también nos permite bloquear todas las solicitudes a nuestro servidor de autenticación, excepto las solicitudes de la URL de nuestro middleware. Esto hace que nuestro servidor de autenticación sea mucho más seguro.

Esto no era posible anteriormente, porque nuestro front-end se estaba comunicando con el servidor de autenticación. Dado que la interfaz significa la computadora del cliente, no pudimos aplicar un filtro de IP.

4) Exposición de API públicas

En la parte anterior, aprendimos que los middlewares pueden usarse para restringir el acceso a nuestra API.

Ahora veamos el otro lado de la ecuación: ¿qué pasa si queremos dar acceso restringido a nuestra API? Quizás somos ingenieros de software en un banco y el banco está planeando un hackathon. Necesitaríamos proporcionar acceso a nuestra API, ¿verdad?

Pero como somos un banco, por supuesto que no podemos proporcionar acceso a toda la API y permitir todas las operaciones. Esto significa que debemos encontrar una forma de proporcionar acceso restringido.

Para este propósito, podemos implementar un middleware que solo expone algunos de los puntos finales y redirige las solicitudes a nuestra API real. Luego proporcionamos esta API a los desarrolladores en el hackathon.

Conclusión

En esta publicación, comenzamos definiendo qué es el middleware y tratamos de categorizar los casos de uso de middlewares en el desarrollo web.

Tenga en cuenta que esta no es una lista completa de casos de uso, pero aún así espero que haya sido útil para usted.

Gracias por leer. Si te gustó el artículo, te invito a que consultes mi blog. También puedes suscribirte a mi lista de correo para recibir notificaciones cuando publique una nueva publicación :)