Aprende a construir peticiones HTTP resistentes con AbortController, timeouts, retry con backoff y protección contra respuestas fuera de orden en interfaces dinámicas.
En producción, las peticiones no siempre responden rápido ni bien: hay timeouts, cortes intermitentes y respuestas antiguas que llegan tarde.
Un flujo robusto de fetch necesita tres pilares: cancelar solicitudes obsoletas, reintentar fallos temporales y validar estados HTTP explícitamente.
Sin estos patrones, la UI puede mostrar datos inconsistentes o generar doble carga innecesaria al backend.
Objetivo de esta lección: diseñar capa de red resiliente y predecible usando abort, retry y control de concurrencia.
Fetch no termina en await: debes pensar en fallos reales de infraestructura.
`fetch` solo rechaza en errores de red; respuestas 404/500 no lanzan por sí mismas. Por eso debes comprobar `response.ok` antes de parsear.
Además, en interfaces con búsquedas o filtros rápidos, necesitas cancelar solicitudes previas para evitar que una respuesta antigua pise la nueva.
Si la respuesta tarda demasiado, cancelas de forma explícita.
Combinar `AbortController` con `setTimeout` permite imponer un límite de espera y liberar la UI cuando la red está degradada.
Recuerda limpiar el timer en `finally` para evitar fugas y comportamientos inesperados.
No reintentes todo sin criterio: define cuándo y cuántas veces.
Un retry lineal/agresivo puede amplificar carga del sistema. Mejor aplica backoff exponencial corto y límite de intentos.
Reintenta solo en errores potencialmente recuperables (timeouts, 429, 503), no en validaciones funcionales.
La respuesta más lenta no debe sobrescribir la más reciente.
En inputs de búsqueda, cada tecla puede lanzar un fetch nuevo. Si no abortas el anterior, una respuesta vieja podría pintar resultados incorrectos.
La combinación de `AbortController` + token/contador de request te da control fino sobre qué respuesta es válida.
Con este protocolo, tu capa de red será más confiable y mantenible.
El valor de estos patrones aparece cuando hay mala red, backend inestable o uso intenso de la interfaz.
Revisar cancelación, reintentos y estados HTTP antes de desplegar evita gran parte de bugs intermitentes difíciles de reproducir.
Aprende a construir peticiones HTTP resistentes con AbortController, timeouts, retry con backoff y protección contra respuestas fuera de orden en interfaces dinámicas.
Código del tema: fetch + AbortController + retry/backoff
Fetch no termina en await: debes pensar en fallos reales de infraestructura.
`fetch` solo rechaza en errores de red; respuestas 404/500 no lanzan por sí mismas. Por eso debes comprobar `response.ok` antes de parsear.
Además, en interfaces con búsquedas o filtros rápidos, necesitas cancelar solicitudes previas para evitar que una respuesta antigua pise la nueva.
Si la respuesta tarda demasiado, cancelas de forma explícita.
Combinar `AbortController` con `setTimeout` permite imponer un límite de espera y liberar la UI cuando la red está degradada.
Recuerda limpiar el timer en `finally` para evitar fugas y comportamientos inesperados.
async function fetchConTimeout(url, ms = 5000) {
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), ms);
try {
const res = await fetch(url, { signal: controller.signal });
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json();
} finally {
clearTimeout(timeoutId);
}
}
document.getElementById('abortable').addEventListener('click', async () => {
const stateEl = document.getElementById('abortState');
stateEl.textContent = 'Lanzando petición... (fallará en 2s)';
try {
// Usamos una URL que responde lento para forzar el timeout
await fetchConTimeout('https://httpbin.org/delay/5', 2000);
stateEl.textContent = 'Éxito (no debería llegar aquí)';
} catch (error) {
stateEl.textContent = `Falló: ${error.message}`;
}
});No reintentes todo sin criterio: define cuándo y cuántas veces.
Un retry lineal/agresivo puede amplificar carga del sistema. Mejor aplica backoff exponencial corto y límite de intentos.
Reintenta solo en errores potencialmente recuperables (timeouts, 429, 503), no en validaciones funcionales.
function esperar(ms) {
return new Promise((resolve) => setTimeout(resolve, ms));
}
async function fetchConRetry(url, maxIntentos = 3) {
let intento = 0;
while (intento < maxIntentos) {
try {
const res = await fetch(url);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return await res.json();
} catch (error) {
intento += 1;
if (intento >= maxIntentos) throw error;
await esperar(300 * 2 ** (intento - 1));
}
}
}La respuesta más lenta no debe sobrescribir la más reciente.
En inputs de búsqueda, cada tecla puede lanzar un fetch nuevo. Si no abortas el anterior, una respuesta vieja podría pintar resultados incorrectos.
La combinación de `AbortController` + token/contador de request te da control fino sobre qué respuesta es válida.
let controladorActivo = null;
async function buscar(q) {
controladorActivo?.abort();
controladorActivo = new AbortController();
const res = await fetch(`/api/search?q=${encodeURIComponent(q)}`, {
signal: controladorActivo.signal
});
if (!res.ok) throw new Error('Error en búsqueda');
return res.json();
}Con este protocolo, tu capa de red será más confiable y mantenible.
El valor de estos patrones aparece cuando hay mala red, backend inestable o uso intenso de la interfaz.
Revisar cancelación, reintentos y estados HTTP antes de desplegar evita gran parte de bugs intermitentes difíciles de reproducir.