Artículo · 2 min
Deja de arreglar problemas del backend en el frontend
La pantalla lenta no era un problema de frontend. Casi nunca lo es. El arreglo pertenece a la capa dueña del problema — y encontrar esa capa es una habilidad.
Cuando una funcionalidad rinde mal, el síntoma aparece en la UI. Una pantalla es lenta. Una vista es torpe. Los datos llegan con la forma equivocada. Y como el síntoma vive en el frontend, ahí es donde los equipos lo arreglan por instinto — un caché del lado del cliente aquí, una petición extra allá, algo de remodelado defensivo de lo que sea que devolvió la API.
Cada workaround es localmente razonable. Juntos, enmascaran el problema en lugar de resolverlo, y el enmascaramiento se acumula con el tiempo.
El patrón, tres veces
La misma situación me encontró en tres productos distintos.
En Sophos, trabajando en un dashboard bancario, los endpoints a veces no devolvían lo que el frontend realmente necesitaba, o las consultas detrás eran lentas. En lugar de contorsionar la UI alrededor de las respuestas, hice ajustes de backend y API — remodelando lo que devolvía el endpoint para que coincidiera con lo que el consumidor necesitaba.
En SmartBeemo, el trabajo de rendimiento consistió en revisar consultas y recortar lo que la API enviaba al frontend, a veces llegando hasta el propio modelo de datos en MongoDB. Eso redujo los tiempos de carga de página en aproximadamente un 25%.
En House Edge, el trabajo fue optimizar consultas de backend sobre conjuntos de datos muy grandes.
Stacks distintos, dominios distintos, la misma jugada cada vez.
El método
Es más un hábito de diagnóstico que una técnica:
- Entender qué necesita realmente el consumidor — normalmente el frontend.
- Analizar el endpoint y la consulta detrás de él.
- Encontrar el over-fetching o la ineficiencia.
- Arreglarlo en la capa que es dueña del problema.
- Confirmar que el frontend sigue comportándose bien.
La mayoría de las veces el problema es over-fetching: la API envía mucho más de lo que la vista necesita, porque se construyó para otro consumidor o se construyó de forma genérica. El frontend puede esconder eso con estados de carga y filtrado en el cliente. O la API simplemente puede dejar de sobre-enviar.
Por qué full-stack es la condición habilitante
Esta es la parte que creo que se subestima: no puedes arreglar en la capa correcta si solo puedes ver una capa. Un ingeniero solo-frontend frente a una pantalla lenta tiene exactamente un lugar donde trabajar, así que ahí es donde se acumulan los workarounds. Trabajar a través del stack significa poder seguir el problema al otro lado del límite y arreglarlo donde vive.
Un arreglo en la capa de API o de datos suele ganarle a tres workarounds en la UI. Resuelve donde el problema realmente está — todo lo que viene después se vuelve más simple.