Notificaciones push y tiempo real en tu app web

Por qué tu app ya no puede permitirse hacer esperar al usuario

Imagina la escena. Un comercial entra en tu CRM, asigna una oportunidad a un compañero y se queda mirando la pantalla. Si tiene que pulsar F5 para comprobar que el cambio se ha guardado, algo va mal. Si encima tiene que avisar por WhatsApp al compañero para que recargue su navegador, hemos perdido la oportunidad de que la herramienta trabaje a favor del equipo.

Esa expectativa de inmediatez —pantallas que cambian solas, alertas que saltan en el momento justo— es lo que separa una aplicación web que la gente usa con gusto de otra que toleran porque no les queda más remedio. Y hablar de notificaciones push tiempo real app web significa, en realidad, hablar de dos cosas que se mezclan demasiado a menudo: lo que pasa dentro de la aplicación con el usuario delante (actualizaciones, chat, colaboración) y lo que pasa fuera, cuando aterrizan avisos en el navegador o el móvil aunque la pestaña esté cerrada. Cada dimensión pide decisiones de arquitectura propias, y mezclarlas con prisa pasa factura en rendimiento, batería y paciencia del usuario.

Las tres rutas técnicas para el tiempo real

Polling: la solución que aguanta hasta que aguanta

El polling es el equivalente digital del niño preguntando "¿ya hemos llegado?". El navegador interroga al servidor cada cierto intervalo. Un setInterval con una llamada fetch cada cinco o diez segundos y a correr.

Funciona. Hasta que deja de funcionar. Un cliente del sector logístico nos contaba cómo su panel, con polling cada tres segundos, tumbó el servidor un lunes cuando 600 operarios entraron a la vez: 12.000 peticiones por minuto y la respuesta es "no hay nada nuevo" el 95% de las veces. El long polling alivia la situación manteniendo la conexión abierta hasta que efectivamente haya datos, pero sigue siendo un parche sobre un HTTP que no se diseñó para esto.

¿Cuándo tiene sentido el polling? Con actualizaciones cada varios minutos, concurrencia por debajo de 100 usuarios o infraestructura que no permite conexiones persistentes. En el resto de casos, mejor pasar de página.

Server-Sent Events (SSE): el carril rápido en un sentido

SSE aprovecha una conexión HTTP estándar que el servidor mantiene abierta para empujar eventos al cliente. El navegador los recibe vía la API EventSource, que gestiona sola la reconexión cuando se cae el enlace. Esa última parte es oro: te ahorra mantener código de reintentos.

Las virtudes son difíciles de discutir: viaja sobre HTTP/2 sin configuraciones exóticas, atraviesa proxies y firewalls corporativos sin pelear y consume menos recursos que un WebSocket. ¿La pega? El canal va en una sola dirección. Si el usuario necesita responder (un mensaje de chat, por ejemplo), seguirá usando peticiones HTTP convencionales, lo que añade latencia cuando la conversación bidireccional es intensa.

SSE encaja como un guante en feeds de actividad, dashboards con datos en vivo, seguimiento de pedidos al estilo "tu pizza sale del horno" o avisos dentro de la aplicación.

WebSockets: la línea directa en ambos sentidos

WebSocket abre una conexión persistente y bidireccional entre cliente y servidor. Tras un handshake HTTP inicial, la comunicación salta a un protocolo propio que permite mandar y recibir mensajes con latencia casi inexistente.

Es la opción para chat, edición colaborativa estilo Google Docs, juegos multijugador, herramientas de trading o cualquier escenario donde ambas partes intercambian datos de forma constante y poco previsible.

El precio es operativo: los WebSockets no se benefician del caching HTTP, te obligan a gestionar reconexiones a mano, pueden dar guerra con proxies corporativos (algún cortafuegos de banco los corta sin avisar) y cada conexión ocupa un socket en el servidor. Cuando creces, vas a necesitar un sistema pub/sub —Redis, RabbitMQ, NATS— para coordinar mensajes entre instancias del backend.

Cómo funcionan de verdad las notificaciones push en el navegador

El flujo push, paso a paso

Las notificaciones push web siguen un protocolo estandarizado por el W3C en el que intervienen tres actores: tu aplicación (cliente y servidor), un service worker instalado en el navegador del usuario y un servicio de push del propio navegador (FCM para Chrome, Mozilla Push Service para Firefox, WNS para Edge).

El recorrido es el siguiente:

1. Tu aplicación pide permiso al usuario para enviarle notificaciones.
2. Si el usuario acepta, el navegador genera una suscripción push con un endpoint único y unas claves de cifrado.
3. Tu servidor guarda esa suscripción asociada al usuario.
4. Cuando quieres avisarle de algo, tu servidor cifra el mensaje con las claves de la suscripción y lo envía al endpoint del servicio push.
5. El servicio push lo entrega al navegador.
6. El service worker recibe el mensaje y decide qué hacer con él, incluso si tu aplicación está completamente cerrada.

Visto así parece sencillo. En la práctica, cada paso tiene su trampa.

El service worker: el portero que nunca duerme

El service worker es un script que el navegador ejecuta en segundo plano, al margen de cualquier pestaña. Recibe los mensajes push y decide el siguiente movimiento: mostrar una notificación del sistema, actualizar un badge, sincronizar datos en caché.

Hay un detalle que muchos equipos pasan por alto y que termina costando caro: el service worker tiene su propio ciclo de vida y no se actualiza con cada despliegue. Los navegadores lo cachean y solo comprueban versiones nuevas cuando el usuario vuelve a entrar. Si despliegas un cambio crítico en el formato del mensaje un viernes a las cinco, habrá usuarios ejecutando el service worker antiguo durante días. La regla: versiona siempre el payload y diseña el service worker para tolerar formatos antiguos durante una ventana razonable.

Pedir permiso sin disparar al pie

Solicitar permiso en el momento equivocado es la vía rápida para que el usuario pulse "Bloquear" y se quede sin recibir notificaciones para siempre. Chrome reduce la visibilidad del prompt si muchos visitantes de tu sitio lo rechazan, así que los pecados de hoy se pagan mañana.

La táctica que mejor funciona es la doble confirmación. Primero muestras un banner propio dentro de la aplicación, en lenguaje claro, explicando qué tipo de avisos enviarás (no es lo mismo "te avisaremos cuando te asignen una tarea" que "recibirás novedades del producto"). Solo cuando el usuario pulsa "Activar" se lanza el prompt nativo. Un cliente del sector retail nos contaba que pasar del prompt directo a este patrón les llevó la aceptación del 12% al 43% en tres semanas.

Firebase, OneSignal o Web Push directo: elegir sin dejarse arrastrar

Firebase Cloud Messaging (FCM). Gratis, bien documentado y con cobertura web y móvil. El lado oscuro es la dependencia de Google: tus suscripciones push viajan por sus servidores, los datos de uso quedan en su ecosistema y la política de retención de mensajes no entregados nunca queda del todo clara.

OneSignal. Aporta una capa de abstracción sobre el protocolo push con segmentación de audiencias, A/B testing y analíticas decentes. El plan gratuito viene con límites de volumen y marca de agua. Es la opción cómoda para equipos de marketing que necesitan lanzar campañas sin pedir hora al departamento técnico.

Web Push Protocol directo. Tirando de la librería web-push (Node.js, Python, PHP, Go) mandas notificaciones al servicio push del navegador sin intermediarios. Controlas todo el flujo, no dependes de terceros y cumples el estándar VAPID. La contrapartida es que la segmentación, las analíticas y la gestión de suscripciones corren de tu cuenta. Para productos corporativos, sanitarios o cualquier escenario donde el control del dato pesa más que la comodidad, suele compensar el esfuerzo.

Cuando creces: colas, pub/sub y escalado horizontal

En cuanto tu aplicación deja de caber en un único servidor, necesitas un mecanismo para que un mensaje generado en el servidor A llegue al usuario conectado al servidor B.

Redis Pub/Sub ofrece un canal ligero y veloz para coordinar WebSockets entre instancias. Librerías como @socket.io/redis-adapter lo resuelven con unas pocas líneas. Punto flaco: no garantiza la entrega. Si un suscriptor no está conectado cuando se publica el mensaje, lo pierde sin avisar.

RabbitMQ entra en juego cuando la fiabilidad importa de verdad: pagos, alertas críticas en hospitales, eventos regulatorios. Aporta colas persistentes con confirmación de entrega. NATS brilla en alta frecuencia gracias a JetStream, que combina streaming y pub/sub.

Un patrón ya probado consiste en separar la capa de WebSocket o SSE en un servicio dedicado —un "gateway de tiempo real"— que se escala horizontalmente detrás de un balanceador con sticky sessions o, mejor, usando Redis como canal de coordinación. La lógica de negocio publica eventos en Redis desde cualquier microservicio y los gateways los reenvían a los clientes conectados.

Los errores que más caros pagan los equipos

No gestionar la reconexión del cliente. Las conexiones WebSocket y SSE se cortan. Punto. El usuario cambia de WiFi al subir al AVE, el servidor se reinicia tras un despliegue, el proxy corporativo cierra conexiones inactivas. Implementa backoff exponencial con jitter para evitar avalanchas de reconexión cuando el servidor vuelva.

Empujar demasiados datos por el canal de tiempo real. El canal debe transportar señales ligeras tipo "hay datos nuevos en la entidad X", no los datos completos. El cliente recibe el aviso y hace un fetch del recurso por la vía normal. Evita problemas de sincronización y reduce ancho de banda.

Ignorar las métricas hasta que se queja un usuario. Monitoriza conexiones activas, latencia de entrega, tasa de reconexiones y porcentaje de notificaciones push entregadas frente a las realmente mostradas. Sin estos números, los problemas aparecen el día que tu mejor cliente llama enfadado.

No prever el modo offline. Si el usuario pierde la conexión 30 segundos y se generan 15 eventos, espera recibirlos al volver. Implementa catch-up basado en el ID del último evento recibido. Trabajo extra hoy, pero te ahorras reabrir la arquitectura en seis meses.

Decide pronto, pagarás menos después

Elegir entre polling, SSE y WebSockets no es un debate académico. Depende del tipo de interacción de tus usuarios, del volumen de mensajes y de cuán crítica sea la entrega. Lo mismo vale para las notificaciones push: un producto B2B con 200 usuarios profesionales tiene necesidades radicalmente distintas a un marketplace con 50.000 cuentas activas.

La regla que repetimos a casi todos los clientes que arrancan un proyecto nuevo es la misma: tomar estas decisiones en el primer sprint cuesta una semana de diseño; tomarlas en el sprint diez, con tráfico ya encima, puede costar una reescritura completa de la capa de comunicación.

Si estás planificando una aplicación que necesita comunicación en tiempo real o notificaciones push y quieres acertar con la arquitectura desde el principio, hablemos sobre tu proyecto. Diseñar bien el tiempo real al inicio evita reescrituras dolorosas cuando ya tienes usuarios reales esperando al otro lado.