Dashboard visual para microservicios con .NET 8, API

En este artículo presento un dashboard microservicios API Gateway desarrollado con .NET 8, ASP.NET Core y JavaScript.

El proyecto tiene un objetivo claro: crear una aplicación visual para consultar varios microservicios desde una sola pantalla. Para conseguirlo, he utilizado un API Gateway como punto de entrada principal.

Gracias a este enfoque, el frontend no necesita llamar directamente a cada servicio. En su lugar, todas las peticiones pasan primero por el Gateway. Después, el Gateway decide qué microservicio debe responder.

Esta solución ayuda a organizar mejor la arquitectura. Además, permite explicar el funcionamiento de los microservicios de una forma mucho más visual.

Objetivo del proyecto

El objetivo principal es transformar una arquitectura de microservicios en una herramienta visual e interactiva.

Normalmente, para probar una API se utilizan herramientas como Swagger o Postman. Sin embargo, en este caso he creado un dashboard propio para hacer la demo más clara.

Desde esta interfaz se pueden ejecutar varias acciones. Por ejemplo, consultar usuarios, consultar inventario, verificar el estado del sistema y simular un pedido.

De esta manera, el proyecto no se queda solo en el backend. También incluye una parte visual que facilita la comprensión de la arquitectura.

Problema que resuelve

En una arquitectura de microservicios, cada servicio tiene una responsabilidad concreta. Un servicio puede encargarse de los usuarios. Otro puede gestionar productos. También puede existir otro servicio para pedidos.

Esta separación tiene muchas ventajas. Por un lado, permite organizar mejor el código. Por otro lado, facilita que cada servicio evolucione de forma independiente.

Sin embargo, también aparece un problema. Si el frontend llama directamente a cada microservicio, necesita conocer varias URLs, varios puertos y varias rutas internas.

Eso provoca más acoplamiento entre la interfaz y el backend. Por este motivo, he utilizado un API Gateway.

Qué es un API Gateway

Un API Gateway es una puerta de entrada única para una arquitectura de microservicios.

El cliente solo se comunica con el Gateway. Después, el Gateway se encarga de enviar cada petición al servicio correspondiente.

Este patrón ayuda a ocultar la complejidad interna del sistema. Además, permite centralizar tareas comunes como seguridad, logs, control de errores y monitorización.

En este proyecto, el API Gateway conecta el dashboard con el servicio de usuarios y el servicio de productos. También incluye un endpoint de HealthCheck y una operación para simular pedidos.

Dashboard microservicios API Gateway

El dashboard microservicios API Gateway es la parte visual de la solución.

Está desarrollado con HTML, CSS y JavaScript. No he utilizado frameworks complejos porque el objetivo era crear una demo sencilla, rápida y fácil de entender.

La interfaz tiene un diseño oscuro tipo panel de control. Además, incluye una consola donde se muestran las respuestas del backend en formato JSON.

Gracias a esta consola, se puede ver de forma directa qué devuelve cada endpoint. Esto hace que la demo sea más clara y más visual.

Arquitectura de la solución

La solución está formada por tres proyectos principales:

ApiGateway
ServicioUsuarios
ServicioProductos

El proyecto ServicioUsuarios contiene los endpoints relacionados con usuarios.

El proyecto ServicioProductos contiene los endpoints relacionados con productos e inventario.

Por último, el proyecto ApiGateway centraliza la comunicación entre el dashboard y los servicios internos.

Esta estructura permite separar responsabilidades. Además, facilita el mantenimiento del código.

Flujo general de funcionamiento

El funcionamiento de la aplicación sigue un flujo sencillo.

Primero, el usuario pulsa un botón en el dashboard. Después, JavaScript realiza una petición HTTP usando fetch.

A continuación, la petición llega al API Gateway. El Gateway procesa la solicitud y llama al microservicio correspondiente.

Finalmente, la respuesta vuelve al dashboard y se muestra en pantalla.

Este flujo permite entender cómo se comunican los servicios dentro de una arquitectura distribuida.

Botones del dashboard

El dashboard incluye cinco botones principales:

Consultar Usuarios
Consultar Inventario
Verificar Estado del Sistema
Simular Pedido
Limpiar Consola

Cada botón ejecuta una acción distinta contra el API Gateway.

Además, cada respuesta queda registrada en la consola visual. Por eso, es fácil seguir la demo paso a paso.

Consultar usuarios

El botón “Consultar Usuarios” llama al endpoint de usuarios del API Gateway.

Cuando se pulsa, el Gateway recibe la petición y llama internamente al servicio de usuarios. Luego, devuelve la respuesta al dashboard.

La información aparece en formato JSON dentro de la consola visual.

Esta funcionalidad demuestra una ventaja importante del Gateway. El frontend no conoce la URL real del microservicio de usuarios. Solo necesita conocer la URL del API Gateway.

Consultar inventario

El botón “Consultar Inventario” obtiene los productos disponibles.

En este caso, el Gateway se comunica con el servicio de productos. La respuesta incluye datos como identificador, nombre, precio y stock.

Este ejemplo simula una consulta típica de inventario. Por ejemplo, podría utilizarse en una tienda online o en una aplicación de gestión interna.

Además, muestra cómo un servicio independiente puede exponer datos sin estar acoplado directamente al frontend.

Verificar estado del sistema

El botón “Verificar Estado del Sistema” llama al endpoint /health.

Este endpoint permite comprobar si el API Gateway está activo. Si responde correctamente, significa que el punto de entrada principal está disponible.

Los HealthChecks son muy importantes en aplicaciones reales. Se utilizan para monitorización, balanceadores de carga y despliegues en la nube.

Por tanto, esta funcionalidad aporta una visión más profesional al proyecto.

Simular pedido

El botón “Simular Pedido” es una de las partes más importantes de la demo.

En esta operación, el Gateway no se limita a redirigir una petición. También realiza una pequeña orquestación entre servicios.

Primero, consulta el servicio de usuarios para validar que el usuario existe. Después, consulta el servicio de productos para comprobar si hay stock suficiente.

Si ambas condiciones se cumplen, el Gateway devuelve un pedido simulado aprobado. En cambio, si algo falla, devuelve un mensaje de error controlado.

Esta operación representa un caso real de negocio. Muchas acciones empresariales necesitan consultar varios microservicios antes de devolver una respuesta final.

Importancia de la orquestación

La orquestación permite coordinar varios servicios desde un punto central.

En este proyecto, el API Gateway coordina usuarios y productos para simular un pedido. Así, el frontend solo realiza una petición.

Toda la lógica de coordinación ocurre en el backend. Como resultado, la interfaz queda más simple y el sistema es más fácil de mantener.

Además, este enfoque permite añadir nuevas reglas de negocio en el futuro sin modificar demasiado el frontend.

Configuración de CORS

CORS es un punto importante en este proyecto.

CORS significa Cross-Origin Resource Sharing. Es un mecanismo de seguridad que utilizan los navegadores para controlar qué aplicaciones pueden llamar a una API.

Si CORS no está configurado correctamente, el navegador puede bloquear las peticiones. Por eso, el API Gateway incluye una política CORS.

Gracias a esta configuración, el dashboard puede comunicarse correctamente con la API.

Además, se evitan errores comunes como Failed to fetch o bloqueos por origen no permitido.

Uso de Fetch API

El frontend utiliza fetch para realizar las peticiones HTTP.

fetch es una API nativa de JavaScript. Permite enviar peticiones al backend de forma sencilla.

En este proyecto, cada botón llama a una función JavaScript. Esa función construye la URL, envía la petición y muestra la respuesta en la consola.

Por tanto, el código del frontend es fácil de entender y de modificar.

Uso de HttpClient

En el backend, el API Gateway utiliza HttpClient.

La forma recomendada de usar HttpClient en ASP.NET Core es mediante IHttpClientFactory.

Este enfoque permite configurar clientes HTTP con nombre. En este caso, hay un cliente para el servicio de usuarios y otro para el servicio de productos.

Cada cliente tiene su URL base y un tiempo máximo de espera.

Gracias a esto, la comunicación entre servicios queda más organizada.

Gestión de errores

Una arquitectura de microservicios debe estar preparada para fallos.

Un servicio puede estar apagado. También puede responder lentamente o devolver un error inesperado.

Por ese motivo, el API Gateway controla los errores al comunicarse con los servicios internos.

Si un microservicio no responde, el Gateway devuelve un mensaje claro. De esta manera, el dashboard no falla sin explicación.

Además, este control de errores ayuda a detectar rápidamente qué parte del sistema tiene problemas.

Pruebas realizadas

Durante la demo se han probado varias operaciones.

En primer lugar, se ha consultado el servicio de usuarios. Esta prueba confirma que el Gateway enruta correctamente la petición.

Después, se ha consultado el inventario. Esta segunda prueba valida la comunicación con el servicio de productos.

También se ha probado el HealthCheck del Gateway. Esta comprobación confirma que el punto de entrada principal está disponible.

Por último, se ha simulado un pedido. Esta operación demuestra que el Gateway puede coordinar varios microservicios en una única acción.

Ventajas del dashboard microservicios API Gateway

Este dashboard microservicios API Gateway aporta varias ventajas.

La primera ventaja es la centralización. Todas las operaciones pasan por un único punto de entrada.

Otra ventaja importante es el desacoplamiento. El frontend no depende directamente de las URLs internas de los microservicios.

Además, la consola visual mejora la claridad de la demo. Cada respuesta se puede ver en pantalla de forma inmediata.

También es una solución escalable. En el futuro se podrían añadir nuevos microservicios sin rehacer toda la interfaz.

Por último, el proyecto ayuda a explicar mejor la arquitectura. Esto es muy útil en una presentación técnica.

Tecnologías utilizadas

Las tecnologías utilizadas en este proyecto son:

ASP.NET Core
.NET 8
API Gateway
Microservicios
HttpClient
HealthChecks
CORS
HTML
CSS
JavaScript
Fetch API
GitHub

Estas tecnologías permiten crear una solución sencilla, pero completa.

Además, todas son herramientas muy utilizadas en entornos reales de desarrollo web y backend.

Estructura del repositorio

El proyecto está organizado en una solución de Visual Studio.

La estructura principal es la siguiente:

Video-GestionPedidos
├── ApiGateway
├── ServicioProductos
├── ServicioUsuarios
├── Start-Demo.ps1
└── Video-GestionPedidos.sln

El archivo Start-Demo.ps1 permite arrancar la demo de forma rápida.

Este script inicia los servicios necesarios para probar el dashboard.

Posibles mejoras futuras

El proyecto se puede ampliar con nuevas funcionalidades.

Una mejora sería añadir autenticación con JWT. Así, el acceso al dashboard y al API Gateway estaría protegido.

También se podrían incorporar logs en tiempo real. De esta forma, sería posible ver las peticiones mientras se ejecuta la demo.

Otra mejora interesante sería añadir métricas y gráficos. Por ejemplo, número de peticiones, errores y tiempos de respuesta.

Además, se podría integrar el sistema con herramientas como Prometheus, Grafana o Application Insights.

Finalmente, la simulación de pedido podría evolucionar hacia un flujo más completo. Podría incluir base de datos, estados de pedido y comunicación asíncrona mediante colas de mensajes.

Conclusión

Este proyecto demuestra cómo crear un dashboard microservicios API Gateway con .NET 8, ASP.NET Core y JavaScript.

La solución permite consultar usuarios, consultar inventario, verificar el estado del sistema y simular un pedido.

Todo se realiza desde una única pantalla.

El API Gateway centraliza la comunicación. Además, simplifica el frontend y permite coordinar operaciones entre varios servicios.

Gracias a este enfoque, la arquitectura es más clara y más fácil de mantener.

También resulta más sencilla de explicar en una demo técnica.

En definitiva, este proyecto es una base práctica para entender los microservicios.

También ayuda a comprender el papel de un API Gateway.

Además, muestra cómo crear una interfaz visual para interactuar con un backend distribuido.

Autor: Óscar López
Máster: Desarrollo Full Stack + Arquitecturas Cloud
Centro: Tajamar Tech
Año académico: 2025-2026

Código https://github.com/oscarlopezdigital-hash/Dashboard-de-Microservicios

Recursos utilizados: