Para real-time sync en un SaaS de nicho con Next.js, la decisión entre WebSockets y polling importa más de lo que parece en la arquitectura inicial. Real-time sync en SaaS Next.js con WebSockets no es siempre la respuesta correcta: usálos cuando el producto necesita interacción simultánea, eventos empujados por el servidor y latencia muy baja percibida. Usá polling cuando el dato puede esperar algunos segundos, la carga es predecible y la simplicidad operativa vale más que la ilusión de tiempo real.
La decisión importa porque en Vercel —el deployment target más común para Next.js SaaS— WebSockets requieren infraestructura adicional que polling no necesita.
La elección correcta depende de 3 variables concretas: frecuencia de actualización, cantidad de clientes simultáneos y tolerancia a latencia. WebSockets mantienen una conexión persistente de 1 a 5 kilobytes por cliente; polling HTTP puede servir 10 veces más clientes con la misma infraestructura. En mis SaaS B2B, el polling con intervalo de 5 segundos cubrió el 90 por ciento de los casos de uso operativos sin necesidad de WebSockets.
Por qué la elección importa más de lo que parece
Tres casos donde polling gana sobre WebSockets en SaaS B2B de nicho:
- Dashboards operativos: latencia de 5-30 segundos es aceptable y la infraestructura es 5 veces más simple.
- Notificaciones de estado: un webhook actualiza la DB y el cliente recoge el cambio en el siguiente ciclo de polling.
- Sistemas multi-tab: polling maneja correctamente múltiples pestañas sin estado compartido de conexión.
El error más frecuente que veo en SaaS de nicho es implementar WebSockets porque "se siente más profesional". WebSockets son la respuesta correcta para algunos problemas. Para otros, son complejidad innecesaria con costos reales.
Costos de WebSockets que el polling no tiene:
- Vercel no soporta WebSockets nativamente: necesitás Pusher, Ably u otro servicio externo, o un servidor separado.
- Las conexiones WebSocket son persistentes: en un SaaS con cientos de usuarios activos simultáneos, el costo puede escalar inesperadamente.
- El debugging de problemas de conexión en producción es más complejo que el debugging de polling.
- Los agentes que operan sobre el sistema necesitan entender la lógica de reconexión, heartbeats y estado de conexión.
Por qué el polling no es "la opción amateur": Polling es la opción correcta cuando el dato puede esperar. En la mayoría de los SaaS de nicho, el "real-time" que el usuario percibe es "actualizado en los últimos 5-10 segundos". Eso es polling.
El criterio de decisión que uso
| Criterio | WebSockets | Polling HTTP |
|---|---|---|
| Latencia típica | menos de 100 milisegundos | 1-30 segundos |
| Carga en servidor | Alta (conexión persistente) | Baja a media |
| Funciona en Vercel serverless | No recomendado | Sí, sin configuración extra |
| Ideal para | Chat en tiempo real, cursores | Dashboards, notificaciones de estado |
| Complejidad de implementación | Alta | Baja |
Elegí WebSockets cuando:
- Múltiples usuarios necesitan ver el estado del otro en tiempo real (edición colaborativa, chat en vivo, dashboards de monitoreo que muestran datos de otros usuarios).
- El servidor necesita empujar eventos al cliente que no pueden perderse (notificaciones críticas de operaciones).
- La latencia perceptible de polling destruye la experiencia del producto.
Elegí polling cuando:
- El usuario ve sus propios datos actualizados periódicamente.
- El dato puede tener 5-30 segundos de staleness sin impacto real en la experiencia.
- El equipo es pequeño y la operabilidad vale más que la performance marginal.
- Estás en Vercel y no querés agregar un servicio de WebSockets externo.
Cómo implemento polling eficiente en Next.js
Uso React Query con refetchInterval configurado según el contexto:
const { data } = useQuery({
queryKey: ['dashboard', tenantId],
queryFn: () => fetchDashboardData(tenantId),
refetchInterval: 15000, // 15 segundos
refetchIntervalInBackground: false, // solo cuando la tab está activa
})
El refetchIntervalInBackground: false es importante: no tiene sentido actualizar datos de una tab que el usuario no está mirando.
Para invalidación inmediata cuando el usuario hace una acción, uso revalidatePath desde Server Actions. Así el polling es el fallback y la invalidación activa cubre los cambios del usuario mismo.
Cómo implemento WebSockets cuando los necesito
Cuando el caso lo justifica, uso Pusher o Ably para WebSockets en Vercel. El server-side empuja eventos a canales por tenant; el client-side los escucha y actualiza el estado local.
La clave es que los canales son por tenant y la autenticación de canal valida que el usuario tiene acceso a ese tenant. El mismo modelo de multi-tenant auth se aplica a los canales WebSocket.
Esta decisión de cuándo usar qué es parte de la filosofía más amplia de criterio técnico antes que framework: el patrón correcto depende del problema, no de cuál se ve más sofisticado.
Polling con backoff adaptativo para casos de baja actividad
Un patrón que uso cuando el producto tiene períodos de baja actividad: polling con intervalo adaptativo. La idea es simple: si los datos no cambiaron en los últimos N polls, aumentar el intervalo. Si cambiaron, volver al intervalo base.
const [pollInterval, setPollInterval] = useState(15000);
const lastDataRef = useRef(null);
const { data } = useQuery({
queryKey: ['dashboard', tenantId],
queryFn: async () => {
const result = await fetchDashboardData(tenantId);
const hasChanged = JSON.stringify(result) !== JSON.stringify(lastDataRef.current);
if (!hasChanged) {
setPollInterval(prev => Math.min(prev * 1.5, 60000)); // max 1 minuto
} else {
setPollInterval(15000); // reset al base
}
lastDataRef.current = result;
return result;
},
refetchInterval: pollInterval,
refetchIntervalInBackground: false,
})
Eso no es una optimización prematura: es evitar que un SaaS con poca actividad genere cientos de requests por hora sin motivo.
Cuándo migrar de polling a WebSockets
A veces empezás con polling y el producto crece hasta un punto donde ya no alcanza. Las señales que me indican que vale la pena migrar:
- Los usuarios reportan que los datos llegan tarde en flujos donde la latencia importa.
- El volumen de requests de polling se vuelve un costo de infraestructura visible.
- El producto suma colaboración en tiempo real que polling no puede simular bien.
La migración no tiene que ser total. Podés mantener polling para módulos donde la latencia no importa y agregar WebSockets solo para los flujos que lo necesitan. Eso reduce la complejidad operativa y el costo al mismo tiempo.
Si estás construyendo un SaaS con Next.js y necesitás decidir entre WebSockets y polling con criterio real, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Cuándo usar WebSockets en lugar de polling en un SaaS Next.js? Cuando el producto necesita interacción simultánea entre usuarios, eventos empujados por el servidor con latencia muy baja percibida, o cuando el dato cambia tan frecuentemente que polling generaría demasiadas requests en vano.
¿Cuándo el polling es mejor que WebSockets en un SaaS de nicho? Cuando el dato puede esperar algunos segundos, la carga es predecible y pequeña, la simplicidad operativa vale más que la ilusión de tiempo real, y no querés mantener conexiones persistentes en Vercel.
¿Cómo implemento polling eficiente en Next.js App Router?
Con React Query o SWR con refetchInterval configurado, refetchIntervalInBackground: false para no actualizar tabs inactivas, e invalidación activa con revalidatePath cuando el usuario hace una acción.
¿Vercel soporta WebSockets? Vercel no soporta WebSockets en funciones serverless. Para WebSockets en producción necesitás un servicio externo (Pusher, Ably) o mover esa parte a un servidor separado.