En este artículo vas a entender las dos estrategias principales para mantener datos frescos en tu aplicación: Polling (tu app pregunta constantemente al servidor) y Subscriptions (el servidor avisa a tu app cuando hay cambios). Vamos a compararlas lado a lado y darte un framework para elegir la correcta según tu caso de uso. Sin atarnos a ninguna tecnología específica, los conceptos aplican ya sea que uses GraphQL, REST, WebSockets, o cualquier otro protocolo o estilo de API.
Imagina que estás usando una app de chat. Envías un mensaje y... ¿cómo sabe tu app que la otra persona ya respondió? ¿Cómo aparecen las notificaciones sin que tú hagas nada? ¿Cómo se actualizan los marcadores de un partido en vivo?
Todas estas experiencias tienen algo en común: necesitan datos frescos sin que el usuario tenga que recargar la página. A esto le llamamos tiempo real (o algo muy cercano a ello). Y hay dos formas principales de lograrlo: que tu app le pregunte al servidor constantemente si hay algo nuevo (Polling), o que el servidor le avise a tu app en el momento que algo cambia (Subscriptions).
¿Qué es Polling?
Polling es la estrategia más simple: tu aplicación le pregunta al servidor "¿hay algo nuevo?" cada cierto tiempo.
Piénsalo como cuando eras niño en un viaje largo por carretera y le preguntabas a tus papás cada 5 minutos: "¿Ya llegamos? ¿Ya llegamos? ¿Ya llegamos?" No importa si la respuesta cambió o no, tú sigues preguntando.
¿Cómo funciona?
Si eres más visual, este diagrama te puede ayudar a entender el flujo:
- Tu app envía una petición al servidor (por ejemplo, cada 5 segundos)
- El servidor responde con los datos más recientes
- Tu app actualiza la interfaz si hay cambios
- Espera el intervalo definido y repite
En JavaScript se ve algo así:
// Polling: preguntar cada 5 segundos
setInterval(async () => {
const datos = await fetch("/api/mensajes");
actualizarInterfaz(datos);
}, 5000);
Simple, ¿verdad? Y esa es precisamente su mayor fortaleza.
Ventajas y desventajas del Polling
| Ventajas | Desventajas |
|---|---|
| Fácil de implementar: Es una petición HTTP normal en un loop | Desperdicio de recursos: Si no hay datos nuevos, la petición fue innecesaria |
| Funciona con cualquier infraestructura: No necesitas nada especial en el servidor | Latencia: Hay un retraso entre que el dato cambia y tu app se entera. Con un intervalo de 5s, en el peor caso tu usuario ve el dato 5 segundos tarde. Con subscriptions, la latencia típica es de ~50-150ms |
| Stateless: Cada petición es independiente, no hay conexiones persistentes | Carga en el servidor: Muchos clientes haciendo polling = muchas peticiones constantes |
| Fácil de debuggear: Puedes ver cada petición en las herramientas de desarrollo del navegador | Tradeoff del intervalo: Intervalo corto = más carga, intervalo largo = más retraso |
💡 Tip importante: El intervalo de polling es una decisión de diseño clave. Un dashboard que muestra métricas cada minuto no necesita polling cada segundo. Ajusta el intervalo a lo que tu usuario realmente necesita ver.
¿Qué son las Subscriptions?
Las Subscriptions invierten el modelo: en lugar de que tu app pregunte constantemente, el servidor le avisa cuando hay algo nuevo.
Siguiendo con la analogía del viaje: en vez de preguntar "¿ya llegamos?" cada 5 minutos, le dices a tus papás "avísenme cuando lleguemos" y te pones a hacer otra cosa. Ellos te avisan solo cuando es necesario.
¿Cómo funcionan?
Si eres más visual, este diagrama te puede ayudar a ver la diferencia con polling:
- Tu app establece una conexión persistente con el servidor (generalmente usando WebSockets)
- Tu app le dice al servidor "avísame cuando cambien los mensajes"
- El servidor mantiene esa conexión abierta
- Cuando hay datos nuevos, el servidor los envía inmediatamente por esa conexión
- Tu app recibe los datos y actualiza la interfaz
En JavaScript:
// Subscription: el servidor te avisa
const conexion = subscribe("/mensajes");
conexion.on("nuevoDato", (datos) => {
actualizarInterfaz(datos);
});
Fíjate en la diferencia: no hay intervalo, no hay loop. Tu app simplemente reacciona cuando llegan datos nuevos.
Ventajas y desventajas de las Subscriptions
| Ventajas | Desventajas |
|---|---|
| Tiempo real verdadero: Los datos llegan al instante, sin retraso | Más complejo de implementar: Necesitas manejar conexiones persistentes, reconexiones, y estado |
| Eficiente: Solo se transfieren datos cuando realmente hay cambios | Infraestructura más sofisticada: El servidor necesita soportar WebSockets o protocolos similares |
| Menos carga innecesaria: No hay peticiones vacías cuando nada cambió | Stateful: El servidor mantiene el estado de cada conexión activa |
| Mejor experiencia de usuario: La app se siente viva y responsiva | Escalabilidad diferente: Miles de conexiones abiertas simultáneas requieren planificación |
💡 Tip importante: Las subscriptions no son magia, por detrás y mientras no vemos a simple vista, tecnologías como WebSockets mantienen una conexión TCP abierta entre el cliente y el servidor. Esto permite comunicación bidireccional, pero también significa que el servidor necesita gestionar el estado de cada conexión. La buena noticia es que no estamos hablando de tecnología experimental, WebSockets es soportado por más del 97% de los navegadores.
🔗 Conexión con nuestra serie: Si vienes siguiendo la serie de GraphQL, te adelanto algo: cuando implementemos subscriptions con AWS AppSync, no vamos a tener que preocuparnos por manejar WebSockets directamente. AppSync se encarga de toda esa infraestructura por nosotros: conexiones, reconexiones, escalabilidad. Nosotros solo definimos qué datos queremos escuchar.
Polling vs Subscriptions: Comparación lado a lado
Este diagrama muestra ambos modelos con el mismo escenario para que veas la diferencia de un vistazo:
| Aspecto | Polling | Subscriptions |
|---|---|---|
| Dirección | Cliente pregunta → Servidor responde | Servidor avisa → Cliente recibe |
| Latencia | Depende del intervalo (segundos) | Casi instantánea (milisegundos) |
| Carga en servidor | Constante (aunque no haya cambios) | Solo cuando hay datos nuevos |
| Complejidad | Baja | Media-Alta |
| Infraestructura | HTTP estándar | WebSockets u otro protocolo persistente |
| Estado | Stateless | Stateful |
| Escalabilidad | Más peticiones = más carga | Más conexiones = más memoria |
| Debugging | Fácil (peticiones HTTP normales) | Más complejo (conexiones persistentes) |
Para ponerlo en perspectiva: si tienes 1,000 usuarios conectados con polling cada 5 segundos, tu servidor recibe 12,000 peticiones por minuto aunque no haya cambiado absolutamente nada. Con subscriptions, esas 12,000 peticiones se convierten en 0 hasta que realmente haya datos nuevos.
¿Cuándo gana Polling?
- Datos que cambian con poca frecuencia (dashboard de métricas diarias)
- Infraestructura simple sin soporte para WebSockets
- Cuando la latencia de unos segundos es aceptable
- Prototipos rápidos donde la simplicidad importa más
¿Cuándo ganan las Subscriptions?
- Datos que cambian constantemente (chat, colaboración en tiempo real)
- La latencia baja es crítica (trading, juegos, notificaciones)
- Muchos eventos por segundo donde polling sería ineficiente
- Experiencias donde el usuario espera actualizaciones instantáneas
💡 Tip: La complejidad de implementar subscriptions se reduce significativamente cuando usas servicios administrados que manejan la infraestructura de WebSockets por ti.
¿Cuándo usar Polling y cuándo usar Subscriptions?
No hay un ganador universal. La mejor opción depende de tu caso de uso específico. Aquí tienes algunos ejemplos para guiarte:
| Caso de uso | Enfoque recomendado | ¿Por qué? |
|---|---|---|
| Chat en tiempo real | Subscriptions | Los usuarios esperan ver mensajes al instante |
| Dashboard de analytics | Polling | Los datos se actualizan cada minutos u horas |
| Feed de redes sociales | Polling (o híbrido) | No necesitas ver cada like al instante |
| Marcadores deportivos en vivo | Subscriptions | Cada segundo cuenta para la experiencia |
| Notificaciones | Subscriptions | El usuario espera recibirlas inmediatamente |
| Reporte de inventario | Polling | Se consulta periódicamente, no en tiempo real |
| Editor colaborativo (tipo Google Docs) | Subscriptions | Cada keystroke necesita sincronizarse |
El enfoque híbrido
Algo que vale la pena mencionar: no siempre tienes que elegir uno u otro. Muchas aplicaciones usan ambos enfoques dependiendo de la funcionalidad.
Por ejemplo, una app de delivery podría usar:
- Subscriptions para el tracking en tiempo real del repartidor
- Polling para actualizar el catálogo de restaurantes cada cierto tiempo
La clave es preguntarte: ¿Qué tan rápido necesita mi usuario ver este cambio?
- Si la respuesta es "inmediatamente" → Subscriptions
- Si la respuesta es "en los próximos segundos o minutos está bien" → Polling
- Si no estás seguro → Empieza con polling (es más simple) y migra a subscriptions si la experiencia lo requiere
Preguntas frecuentes
¿Qué es long polling?
Long polling es un punto intermedio entre polling y subscriptions. En vez de preguntar cada X segundos y recibir una respuesta inmediata (aunque esté vacía), tu app hace una petición y el servidor la mantiene abierta hasta que tenga datos nuevos. Cuando responde, tu app inmediatamente hace otra petición. Es más eficiente que polling tradicional pero no tan eficiente como subscriptions con WebSockets.
¿Las subscriptions consumen más recursos que polling?
Depende. Las subscriptions mantienen conexiones abiertas, lo que consume memoria en el servidor por cada cliente conectado. Polling consume ancho de banda y CPU por cada petición repetida. Con pocos usuarios y cambios frecuentes, subscriptions es más eficiente. Con muchos usuarios y cambios poco frecuentes, polling puede ser más simple de escalar.
¿Se pueden combinar polling y subscriptions?
Sí, y es más común de lo que parece. Muchas aplicaciones usan subscriptions para funcionalidades que necesitan tiempo real (como chat o notificaciones) y polling para datos que cambian con menos frecuencia (como un catálogo de productos). No tienes que elegir uno para toda tu aplicación, puedes usar el enfoque que mejor se adapte a cada funcionalidad.
Conclusión
Recapitulemos lo que aprendimos:
- Polling = tu app pregunta constantemente. Simple, stateless, pero puede ser ineficiente
- Subscriptions = el servidor te avisa. Eficiente y en tiempo real, pero más complejo
- No hay un "ganador" cada enfoque tiene su lugar dependiendo de tu caso de uso
- Los enfoques híbridos son completamente válidos y muy comunes en aplicaciones reales
La próxima vez que estés diseñando una funcionalidad que necesite datos frescos, ya tienes las herramientas conceptuales para tomar una decisión informada.
En el próximo artículo de la serie, vamos a poner estos conceptos en práctica implementando subscriptions en nuestra API de GraphQL con AWS AppSync. ¿Recuerdas toda la complejidad que mencionamos sobre manejar WebSockets, conexiones persistentes y reconexiones? AppSync se encarga de todo eso por nosotros, por debajo usa los mismos WebSockets que explicamos aquí, pero nosotros solo necesitamos definir qué datos queremos escuchar. Vamos a ver cómo pasar de la teoría a código funcionando.
Top comments (0)