Crear un Dashboard de IA usando Angular Signals y RxJS

Creando un “AI-Powered Dashboard” con Angular Signals

Tiempo estimado de lectura: 4 min

Introducción

En este artículo verás cómo combinar RxJS y Signals para manejar flujos de datos en tiempo real provenientes de una IA (por ejemplo, análisis de sentimientos) y cómo transformar ese stream en métricas, alertas y automatizaciones sin perder rendimiento ni claridad arquitectónica.

Resumen rápido (lectores con prisa)

Signals convierte asincronía en estado síncrono y derivable.

Usa RxJS para transporte, reconexión y agregación; convierte Observables a Signals con toSignal().

Deriva métricas con computed() y ejecuta IO con effect() sin mutar Signals.

Buffer razonable y debouncing en la capa RxJS para evitar re-renders masivos.

Por qué Signals importa en un dashboard de IA

Signals convierte asincronía en estado síncrono y derivable. Para un dashboard que recibe cientos de eventos por segundo (SSE, WebSocket, o streaming desde un LLM), Signals evita re-renders masivos porque computed() memoriza resultados y effect() dispara efectos solo cuando cambian las dependencias. Eso no reemplaza a RxJS: lo complementa. Usa RxJS para controlar transporte y temporalidad; usa Signals para la “última milla” del estado en memoria.

Documentación útil: Angular Reactivity / Signals, RxJS, Server-Sent Events (SSE), n8n.

Arquitectura propuesta (3 capas)

1. Transporte (RxJS): reconexión, parsing, retries, debounce y buffer.

2. Puente (toSignal): convierte Observable → Signal para el componente.

3. Derivación UI (computed / effect): métricas, temas visuales y triggers externos.

Esta separación mantiene responsabilidades claras y facilita testing.

Transporte (RxJS)

RxJS maneja reconexiones, parsing y temporalidad. Mantén lógica de reconexión y buffering fuera del componente.

Puente (toSignal)

Convierte streams a Signals para que la UI consuma estado derivado sin suscripciones manuales en el componente.

Derivación UI (computed / effect)

Usa computed() para métricas derivadas y effect() solo para IO como llamadas a webhooks o telemetría.

Ejemplo práctico: ingesta y buffer con RxJS

Servicio que consume un SSE del backend que devuelve análisis de sentimiento por mensaje.

ai-stream.service.ts

// ai-stream.service.ts
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';
import { scan, retryWhen, delay, tap } from 'rxjs/operators';

export interface SentimentEvent {
  id: string;
  ts: number;
  score: number; // -1..1
  source?: string;
}

@Injectable({ providedIn: 'root' })
export class AiStreamService {
  connectStream(): Observable<SentimentEvent> {
    return new Observable<SentimentEvent>((obs) => {
      const es = new EventSource('https://api.tu-backend.com/ai-sentiment');
      es.onmessage = e => {
        try { obs.next(JSON.parse(e.data)); } catch { /* drop */ }
      };
      es.onerror = () => { es.close(); obs.error(new Error('SSE error')); };
      return () => es.close();
    }).pipe(
      retryWhen(errors => errors.pipe(tap(() => console.warn('reconnecting...')), delay(2000)))
    );
  }

  getHistory(buffer = 50) {
    return this.connectStream().pipe(
      scan((acc: SentimentEvent[], cur: SentimentEvent) => [...acc, cur].slice(-buffer), [])
    );
  }
}

RxJS maneja reconexiones y parsing; nunca mezcles esa lógica en el componente.

Puente: toSignal() y derivaciones con computed()

En el componente convertimos el Observable en Signal y derivamos métricas con computed().

dashboard.component.ts

// dashboard.component.ts
import { Component, computed, inject, effect } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { AiStreamService } from './ai-stream.service';

@Component({ selector: 'app-dashboard', standalone: true, templateUrl: './dashboard.html' })
export class DashboardComponent {
  private svc = inject(AiStreamService);
  feed = toSignal(this.svc.getHistory(), { initialValue: [] });

  average = computed(() => {
    const list = this.feed();
    if (!list.length) return 0;
    return list.reduce((s, e) => s + e.score, 0) / list.length;
  });

  theme = computed(() => {
    const a = this.average();
    if (a < -0.6) return 'critical';
    if (a < -0.2) return 'warning';
    return 'ok';
  });

  constructor() {
    // ejemplo de efecto para automatización:
    effect(() => {
      const a = this.average();
      if (a < -0.8) this.sendAlert(a);
    });
  }

  private sendAlert(score: number) {
    fetch('https://hooks.tu-n8n-host/webhook/alert', {
      method: 'POST', body: JSON.stringify({ level: 'critical', score }), headers: { 'Content-Type': 'application/json' }
    }).catch(e => console.error('alert failed', e));
  }
}

Plantilla (snippet) lee Signals directamente: {{'{{ average() }}'}} y *ngFor="let e of feed()".

Buenas prácticas y criterios técnicos

• Buffer razonable: mantener los últimos N eventos (50–200) evita crecimiento de memoria y te permite cálculos rápidos.
• Debounce/agregación: si la IA envía ráfagas, agrupa en la capa RxJS (bufferTime, auditTime) antes de exponer a Signals.
• No mutar Signals desde effect(): usa efectos solo para IO. Mutaciones entre Signals pueden crear ciclos.
• Telemetría: registra métricas (latencia, eventos perdidos, reconexiones) a un backend no sensible. No envíes datos de usuarios por defecto.
• Fallback: si el navegador del cliente falla en aceptar SSE/WebSocket, contempla polling adaptativo con RxJS.
• Test: prueba unitaria de computed functions y mocking del Observable; el puente toSignal facilita el test porque el componente ve estado sin suscripciones manuales.

Resumen ejecutivo

Creando un “AI-Powered Dashboard” con Angular Signals significa delegar control de red a RxJS y responsabilidad de estado derivado a Signals. Esa combinación reduce código boilerplate, mejora rendimiento y facilita integraciones de automatización (n8n, Slack, PagerDuty).

Es un patrón práctico: RxJS para la tubería; Signals para la memoria y la UI. Implementa buffers, agrega debouncing en la capa correcta y usa effect() exclusivamente para IO. Con esto obtienes un dashboard que reacciona en tiempo real sin convertirse en una pesadilla de mantenimiento.

Dominicode Labs

Para ejemplos prácticos y experimentos relacionados con automatización e IA aplicada, revisa Dominicode Labs. Es una continuación lógica para poner en producción automatizaciones y workflows conectados a dashboards en tiempo real.

FAQ

• ¿Cómo probar las computed functions?
• ¿Dónde aplicar buffering vs debouncing?
• ¿Qué hace toSignal() y por qué usarlo?
• ¿Cuándo usar effect() en lugar de computed()?
• Recomendaciones para reconexiones SSE
• ¿Qué considerar sobre telemetría y privacidad?

Respuesta: ¿Cómo probar las computed functions?

Mockea el Observable que alimenta el puente (toSignal) y crea señales con valores controlados. Invoca la función computed() en aislamiento y valida su salida para varios escenarios de datos. Las pruebas unitarias deben cubrir casos borde (lista vacía, valores extremos de score).

Respuesta: ¿Dónde aplicar buffering vs debouncing?

Aplica buffering y agregación en la capa RxJS cuando necesites agrupar ráfagas antes de exponer al UI. Usa debouncing para reducir frecuencia de updates; usa bufferTime/auditTime para agrupar eventos. Mantén Signals como consumidor de estado preprocesado.

Respuesta: ¿Qué hace toSignal() y por qué usarlo?

toSignal() convierte un Observable en una Signal que el componente puede leer síncronamente. Simplifica la UI eliminando suscripciones manuales y facilita testing al ver estado como valor directo.

Respuesta: ¿Cuándo usar effect() en lugar de computed()?

Usa computed() para derivar valores puros y memorizar resultados. Usa effect() para efectos secundarios e IO (ej. webhooks, telemetría). No mutes Signals desde un effect(); los efectos deben ser consumidores externos.

Respuesta: Recomendaciones para reconexiones SSE

Gestiona reconexión en la capa RxJS con retryWhen y backoff. Registra eventos de reconexión y errores para telemetría. Considera fallback a polling adaptativo si SSE/WebSocket no está disponible.

Respuesta: ¿Qué considerar sobre telemetría y privacidad?

Registra métricas no sensibles (latencia, eventos perdidos, reconnects). Evita enviar datos de usuarios por defecto; anonimiza o agrega datos antes de exportarlos. Mantén cumplimiento de políticas de privacidad para datos PII.