Consumir APIs en frontend parece algo simple. Un fetch, un await, y listo.
Pero en cuanto la aplicación crece un poco, empiezan los problemas: estados inconsistentes, loaders que no desaparecen, errores que no sabes dónde manejar y componentes que se vuelven imposibles de mantener.
La realidad es que consumir APIs correctamente no es solo hacer una petición. Es diseñar cómo tu aplicación se comunica con el servidor de forma estable, predecible y escalable.
En este artículo vamos a ver cómo hacerlo bien en un frontend moderno, evitando los errores más comunes y construyendo una base sólida.
El problema real: no es el fetch, es la arquitectura
Muchos desarrolladores empiezan así:
useEffect(() => {
fetch("/api/users")
.then(res => res.json())
.then(setUsers);
}, []);Y aunque esto funciona, no escala.
El problema no está en fetch en sí, sino en que no hay una separación clara entre responsabilidades. El componente termina manejando la petición, el estado, los errores y la UI al mismo tiempo.
A medida que repites este patrón en toda la aplicación, el código empieza a duplicarse y se vuelve difícil de mantener.
En aplicaciones modernas, el objetivo no es solo obtener datos, sino controlar todo el ciclo de vida de esos datos.
Separar la lógica de datos de la UI
Uno de los cambios más importantes que puedes hacer es dejar de consumir APIs directamente dentro de los componentes.
En su lugar, puedes abstraer esa lógica:
export async function getUsers() {
const res = await fetch("/api/users");
if (!res.ok) {
throw new Error("Error fetching users");
}
return res.json();
}Esto parece un cambio pequeño, pero tiene un impacto enorme.
Ahora la lógica de datos está separada, es reutilizable y mucho más fácil de testear. El componente deja de preocuparse por los detalles de la petición y se enfoca en renderizar.
Este tipo de separación es la base de cualquier arquitectura frontend escalable.
Manejo de estados: loading, error y success
Uno de los errores más comunes es no manejar correctamente los estados de una petición.
Cada llamada a una API tiene al menos tres estados:
- loading
- success
- error
Ignorar esto lleva a interfaces inconsistentes.
Un ejemplo básico:
const [users, setUsers] = useState([]);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
useEffect(() => {
getUsers()
.then(setUsers)
.catch(setError)
.finally(() => setLoading(false));
}, []);Esto ya es mejor, pero sigue teniendo problemas.
A medida que la aplicación crece, este patrón se repite constantemente y empieza a ser difícil de mantener.
Por eso surgen herramientas que abstraen este comportamiento.
TanStack Query: cuando la complejidad aumenta
Aquí es donde entra TanStack Query.
En lugar de manejar manualmente estados, caché y sincronización, puedes delegar esa responsabilidad:
import { useQuery } from "@tanstack/react-query";
const { data, isLoading, error } = useQuery({
queryKey: ["users"],
queryFn: getUsers,
});Esto no solo simplifica el código, sino que añade funcionalidades importantes:
- caching automático
- revalidación
- evitar peticiones duplicadas
- sincronización en segundo plano
Intentar implementar todo esto manualmente es posible, pero no vale la pena en la mayoría de los casos.
En frontend moderno, usar una herramienta como esta suele ser la decisión correcta.
fetch vs axios: ¿importa realmente?
Esta es una de las preguntas más comunes.
La realidad es que hoy en día la diferencia no es tan crítica.
Fetch es nativo, ligero y suficiente para la mayoría de los casos. Axios ofrece algunas comodidades adicionales como interceptores o configuración más sencilla.
Pero el problema rara vez está en la herramienta.
Lo importante es cómo organizas el consumo de datos, no qué librería usas.
Puedes construir una arquitectura sólida con cualquiera de los dos.
Server Actions y el cambio de paradigma
Con frameworks como Next.js, están apareciendo nuevas formas de trabajar con datos.
Las Server Actions permiten mover parte de la lógica al servidor, reduciendo la necesidad de consumir APIs directamente desde el cliente.
"use server";
export async function createUser(data) {
// lógica en servidor
}Esto cambia el enfoque en algunos casos, especialmente en formularios o mutaciones.
Sin embargo, no reemplaza completamente el consumo de APIs. Más bien añade otra herramienta al arsenal.
Saber cuándo usar cada enfoque es lo que marca la diferencia.
Errores comunes que deberías evitar
Uno de los más habituales es mezclar lógica de datos con UI. Esto hace que los componentes crezcan demasiado y sean difíciles de mantener.
Otro error es no manejar correctamente los errores, lo que termina en experiencias de usuario pobres o fallos silenciosos.
También es común duplicar lógica de fetching en múltiples componentes, en lugar de centralizarla.
Y quizás el más importante: no pensar en el ciclo de vida de los datos, lo que lleva a inconsistencias en la aplicación.
Evitar estos errores desde el inicio puede ahorrarte muchos problemas a futuro.
Conclusión
Consumir APIs en frontend moderno no se trata de hacer peticiones, sino de diseñar cómo fluye la información en tu aplicación.
Separar responsabilidades, manejar correctamente los estados y usar herramientas adecuadas son las claves para construir aplicaciones mantenibles.
A medida que tu proyecto crece, estas decisiones marcan la diferencia entre un código que escala y uno que se rompe.
Y en la práctica, eso es lo que define la calidad de un frontend.
