Introducción a Aspire 9.5: empiece rápidamente con esta herramienta esencial

Inicio e instalación de Aspire 9.5

Tim comienza explicando el propósito de Aspire. Todo desarrollador .NET que cree API o aplicaciones web debería conocer esta herramienta esencial de Microsoft. Ha habido confusión sobre lo que Aspire puede hacer, por lo que Tim se propone demostrar su propósito, configuración y uso desde el principio.

Abre Visual Studio e inicia un nuevo proyecto utilizando la plantilla Aspire starter app. Si no tienes Aspire instalado, señala el sitio web de Microsoft para la configuración y las herramientas para Aspire, señalando que se puede instalar a través de .NET CLI, Visual Studio o VS Code. Para simplificar, Tim recomienda utilizar el comando CLI:

dotnet nueva instalación aspire.templates

Esto instala las plantillas de proyecto más recientes, incluida Aspire 9.5. Tras la instalación, es posible que Visual Studio deba reiniciarse para que aparezcan las plantillas.

Tim selecciona la aplicación de demostración de Aspire, elige .NET 9, activa HTTPS y utiliza la integración de Redis para el almacenamiento en caché. Esto demuestra un escenario del mundo real en el que Aspire gestiona toda una aplicación localmente. Se salta las pruebas unitarias y procede a crear los archivos de la solución.

Explorando la estructura del proyecto y el modelo de aplicación

Una vez generado el proyecto, Tim desglosa los archivos de proyecto creados por el modelo de aplicación de Aspire. La solución incluye cuatro proyectos principales que reflejan tanto los proyectos típicos de .NET como los específicos de Aspire:

1. Proyecto web: una aplicación web basada en Blazor.

2. Servicio API: servicio de backend para datos o lógica empresarial.

3. AppHost - el archivo único AppHost que lanza toda la aplicación.

4. ServiceDefaults - una biblioteca que contiene comprobaciones de salud, descubrimiento de servicios y configuración de telemetría.

Las dos primeras representan un sistema distribuido normal (frontend y backend), mientras que las otras dos representan la cadena de herramientas unificada de Aspire para la gestión de variables de entorno, dependencias y API de eventos del ciclo de vida de los recursos.

Tim destaca cómo este nuevo modelo de aplicación proporciona un soporte de primera clase para la orquestación multiproyecto, permitiendo a los desarrolladores ejecutar toda su aplicación con un solo comando. AppHost controla el orden de inicio y las dependencias, mientras que ServiceDefaults inyecta automáticamente valores predeterminados de configuración, comprobaciones de estado e integración de telemetría.

Por qué Aspire simplifica el desarrollo local

Tim explica las dificultades de gestionar un sistema distribuido localmente sin Aspire. Tradicionalmente, los desarrolladores deben configurar manualmente los tiempos de ejecución de los contenedores, el reenvío de puertos y las cadenas de conexión de cada servicio. Cada desarrollador debe reproducir individualmente las variables de entorno, los secretos de usuario y las conexiones redis o API.

Con Aspire, la CLI de Aspire se encarga de ello automáticamente. Esta herramienta pone en marcha dependencias como contenedores Redis a través de un contenedor de desarrollo o una instancia Docker, gestiona el descubrimiento de puntos finales y proporciona acceso privado entre servicios mediante el descubrimiento de servicios.

Aspire utiliza un proxy inverso y un sistema de resolución de extremos para que la interfaz web no tenga que conocer los números de puerto codificados. Simplemente se refiere a la API por su nombre (como "apiservice") y Aspire se encarga del resto.

Esto mejora drásticamente la experiencia del desarrollador al eliminar los tediosos pasos de configuración, lo que permite a los desarrolladores centrarse en el código, no en la infraestructura.

Definición de servicios y dependencias en AppHost

Tim muestra el corazón de la configuración de Aspire: el archivo Program.cs de AppHost. Utilizando un patrón constructor var, Aspire define cada servicio con comandos sencillos como:

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

Esta sintaxis define cada recurso, establece el orden de dependencia y crea un ciclo de vida claro de los recursos. Aspire gestiona automáticamente la espera de dependencias, garantizando que primero se inicie la caché, luego la API y, por último, el frontend web.

Este pequeño conjunto de instrucciones ofrece a los desarrolladores un control granular sobre el comportamiento de arranque, reflejando cómo se ejecutarían las cosas en aplicaciones distribuidas listas para producción.

Ejecutar Aspire y comprender el panel de control

Cuando Tim ejecuta el proyecto, Aspire lanza su propio tiempo de ejecución de contenedor y abre Aspire Dashboard, una interfaz central para supervisarlo todo. Inicialmente, aparece un error: "Container runtime unhealthy"-Docker no se estaba ejecutando. Una vez que se inicia Docker, Aspire inicializa automáticamente un recurso ejecutable Redis y lo conecta al resto de la aplicación.

El panel de control muestra iconos de estado codificados por colores que indican el estado de cada recurso. Una vez que Redis, la API y la interfaz web están en funcionamiento, el panel de control se vuelve verde, lo que indica que toda la aplicación funciona correctamente.

Este sistema de notificación refleja instantáneamente los estados en tiempo real, proporcionando mensajes de error más claros que los registros de consola estándar. Los desarrolladores pueden visualizar relaciones de servicio, supervisar métricas e incluso acceder a puntos finales de recursos directamente desde la interfaz de usuario.

Percepciones visuales a través del panel de Aspire

La vista gráfica del panel de control muestra cómo se conectan los servicios. Por ejemplo, la interfaz web se conecta tanto a Redis como al servicio API, mientras que la API es independiente. Esta vista de rastreo ayuda a comprender el flujo interno de llamadas y dependencias.

Tim destaca que el cuadro de mandos incluye mejoras en los detalles de las trazas, como la visualización de opciones de filtrado de trazas y desgloses temporales. Los desarrolladores pueden rastrear las peticiones HTTP a través de los servicios y ver los impactos en el rendimiento utilizando la vista de trazas de Aspire.

Registro centralizado y registros estructurados

Aspire unifica los registros de consola de todos los archivos de proyecto en una sola vista. En lugar de hacer malabarismos con varias ventanas de registro, los desarrolladores pueden utilizar el panel de control para ver los registros de todos los servicios (aplicación web, API e integración de Redis) en una sola línea temporal.

Tim muestra que Aspire utiliza un registro estructurado que permite entradas ricas en contexto, como ID, parámetros y etiquetas. Los desarrolladores pueden filtrar los registros por nivel (Información, Advertencia, Error) o valores de propiedad.

Por ejemplo, un desarrollador sólo puede ver las entradas en las que "evenOddResult" == "odd". Este filtrado avanzado de registros, combinado con los prefijos codificados por colores de Aspire, hace que la depuración sea intuitiva y visual.

Trabajar con trazas y telemetría

En la pestaña Traces, Tim muestra cómo Aspire realiza el seguimiento de las solicitudes a través de los servicios de la aplicación. Cada traza contiene la temporización, el estado y los intervalos que muestran qué servicio procesó qué.

Por ejemplo, una solicitud "GetWeather" muestra cuándo se ha alcanzado o no la caché, cuándo se ha producido la llamada a la API y cuánto tiempo ha durado cada acción. Este filtrado de trazas permite identificar con precisión los cuellos de botella y las dependencias.

Aspire también es compatible con OpenTelemetry para exportar datos de rastreo a otras herramientas o sistemas, lo que ofrece a los desarrolladores una observabilidad completa a través de servicios distribuidos.

Métricas en tiempo real y supervisión del rendimiento

Tim explora métricas como la duración de las solicitudes, las conexiones activas de SignalR y el recuento de solicitudes activas. Estas métricas visualizan el estado en tiempo real de su aplicación y proporcionan una detección temprana de problemas de conexión o latencia.

Los datos de las métricas de Aspire 9.5 también se benefician de mejoras en los detalles de las trazas y en el filtrado de las mismas, lo que permite a los desarrolladores determinar con precisión dónde se producen las caídas de rendimiento en tiempo real.

Aspire es para desarrollo local, no para producción

Tim señala claramente que el panel de Aspire no está pensado para su despliegue en servidores de producción. Su despliegue expondría detalles internos del sistema y variables de entorno, lo que podría ser arriesgado.

No obstante, los desarrolladores pueden seguir utilizando el comando aspire deploy de Aspire para publicar servicios en Azure Container Apps, Azure Container App Jobs u otras integraciones de Aspire. Estas opciones de despliegue están creciendo, pero permanecen separadas del panel de control.

El propósito de Aspire es reflejar localmente un entorno similar al de producción con actualizaciones seguras y soporte de vista previa, no sustituir a los sistemas de monitorización de producción.

Experimentando con el registro y el manejo de excepciones

Tim añade un registro estructurado en la página Counter e introduce deliberadamente una NotImplementedException en la página Weather. Cuando se vuelve a ejecutar, el cuadro de mandos captura inmediatamente tanto los registros estructurados como las excepciones no gestionadas.

Muestra cómo los registros de Aspire muestran todos los detalles, incluido el nombre del parámetro, los valores y la pila de llamadas. La integración con GitHub Models y Copilot AI permite explicaciones automáticas de excepciones y sugerencias de código para correcciones, un ejemplo de los primeros servicios de IA y de la integración del visualizador de IA generativa en la experiencia del desarrollador.

Análisis de errores con filtrado de trazas

En la pestaña Traces, Tim muestra cómo las llamadas a API fallidas aparecen con iconos rojos de exclamación. Al hacer clic en uno de ellos, se muestran todos los registros relacionados filtrados por ID de tramo, vinculando cada solicitud a varios proyectos .NET.

Esta vista unificada -registros, trazas y comprobaciones de estado combinados- proporciona indicaciones interactivas para depurar y crear sistemas observables sin configuración externa.

Integración de Aspire en proyectos .NET existentes

A continuación, Tim explica cómo integrar Aspire en una aplicación existente. Los desarrolladores sólo tienen que añadir dos cosas:

• El proyecto AppHost, que controla qué servicios se inician y sus dependencias.

• El proyecto ServiceDefaults, que proporciona indicadores de características, comprobaciones de estado, telemetría y descubrimiento de servicios.

Al hacer referencia a ServiceDefaults en cada archivo de proyecto, los desarrolladores obtienen automáticamente variables de entorno predeterminadas, configuración de registro y telemetría. El sistema de resolución de extremos de Aspire elimina la necesidad de redireccionar puertos manualmente o de gestionar cadenas de conexión.

Expansión de Aspire más allá del uso local

Tim aborda cómo las capacidades de Aspire se están expandiendo más allá del uso local. Con las integraciones de Azure Container Apps y Azure AI Foundry, los desarrolladores pueden utilizar Aspire CLI para implementar sistemas distribuidos con una configuración mínima.

El sistema ya admite iconos de recursos personalizados, propiedades de nombres y soporte de vista previa para servicios de ai como puntos finales de OpenAI o conexiones PostgreSQL de Azure.

La cadena de herramientas unificada de Aspire también es compatible con el control de versiones y las actualizaciones seguras entre versiones principales y secundarias, lo que ayuda a los equipos a adoptar actualizaciones como Aspire 9.5 con confianza.

Pensamientos finales y perspectivas de futuro

Como concluye el vídeo, Tim llama a Aspire "una mina de oro para los desarrolladores" El panel de control combina la vista de trazas, las comprobaciones de estado, los registros y las métricas en un único panel unificado, algo que antes no estaba disponible en el desarrollo local.

Para Tim y su equipo, cada nuevo proyecto de .NET Aspire utiliza ahora este sistema por defecto. Agiliza las compilaciones personalizadas, mejora la experiencia del desarrollador y garantiza que las aplicaciones distribuidas listas para la producción se comporten de forma coherente en todos los equipos.

Señala que las principales versiones de Aspire seguirán perfeccionando el filtrado de rastros, la resolución de puntos finales y las integraciones de ai, al tiempo que se mantendrá el enfoque en las actualizaciones seguras y la disponibilidad general.

Tim anima a todo el mundo a explorar Aspire 9.5, a utilizarlo en sus próximos proyectos .NET y a aprovechar su sencillez con un solo comando para ver registros, gestionar túneles de desarrollo y probar toda la aplicación localmente con confianza.