Por qué tiempo real: del preguntar al empujar

Hasta ahora tu app PREGUNTA por los datos: hace una petición, recibe respuesta, y hasta la próxima. Pero muchas experiencias modernas necesitan que el servidor EMPUJE los cambios al instante: un chat, un dashboard que se actualiza solo, notificaciones, "Mi Bolsillo" sincronizado entre tu móvil y tu portátil. Eso es tiempo real. Hoy entiendes la diferencia entre preguntar (pull) y empujar (push), y por qué los WebSockets cambian las reglas.

El cartero y el timbre

Pull vs push

El polling: el mal sustituto

Antes de los WebSockets, "simular" tiempo real se hacía con POLLING: preguntar cada pocos segundos. Funciona, pero es un desperdicio:

// ❌ POLLING: preguntar cada 3s "¿hay novedades?"
setInterval(() => {
this.http.get<Gasto[]>('/api/gastos').subscribe((g) => this.gastos.set(g));
}, 3000);
// problemas: latencia (hasta 3s de retraso), peticiones inútiles (la mayoría sin cambios),
// carga innecesaria en el servidor, y no escala con muchos usuarios

El polling tiene tres males: LATENCIA (te enteras hasta el próximo intervalo), DESPERDICIO (la mayoría de las peticiones no traen nada nuevo) y CARGA (multiplica el tráfico al servidor). Un WebSocket resuelve los tres: una sola conexión abierta, cero peticiones repetidas, aviso instantáneo.

Un servidor que empuja, en vivo

Vamos a simular la ESENCIA del push: un "servidor" que, por su cuenta, empuja datos nuevos a intervalos, y un cliente que reacciona. Fíjate en que el cliente NO pregunta —solo escucha—:

Observa el cambio de mentalidad: el cliente registra un handler con alRecibir y luego NO hace nada más —los datos LLEGAN solos y el total se actualiza en vivo—. En Angular real, ese alRecibir alimentaría una SEÑAL, y el template se repintaría solo con cada empujón. El servidor es quien toma la iniciativa; el cliente solo reacciona. Esa inversión es la esencia del tiempo real.

Mini-reto

En el playground: 1) haz que el servidor empuje, además del gasto, una CATEGORÍA aleatoria; 2) en el cliente, lleva un acumulador por categoría (un objeto) y muéstralo en cada empujón; 3) añade un segundo cliente (otro alRecibir) que solo cuente cuántos empujones han llegado. Nota que ambos clientes reciben los mismos datos sin preguntar —un servidor, varios oyentes—.

Qué sigue

Entiendes el modelo push. Ahora la tecnología concreta: la API WebSocket nativa del navegador —los cuatro momentos de una conexión (abrir, mensaje, error, cerrar)— y cómo integrarla con señales en Angular. La próxima lección abre tu primera conexión de tiempo real.