El error de crear APIs cuando ya tienes los datos ⚠️
A veces, la solución más 'limpia' arquitectónicamente es la más lenta de implementar y la más costosa de mantener. Estábamos gestionando el mantenimiento de decenas de sitios web. El problema era simple pero agotador: l
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
arquitectura de software
Fuente
dev.to
Puntos clave
- A veces, la solución más 'limpia' arquitectónicamente es la más lenta de implementar y la más costosa de mantener.
- Estábamos gestionando el mantenimiento de decenas de sitios web. El problema era simple pero agotador: los logs eran puro texto. Para saber qué sitio se estaba procesando, el operador tenía que leer líneas y líneas de co
- El insight clave: No necesitábamos un nuevo endpoint de estado en el backend. La información ya estaba viajando en el stream de logs hacia el frontend.
- Así lo resolvimos con un enfoque minimalista y eficiente:
Bloque 1
A veces, la solución más 'limpia' arquitectónicamente es la más lenta de implementar y la más costosa de mantener.
Estábamos gestionando el mantenimiento de decenas de sitios web. El problema era simple pero agotador: los logs eran puro texto. Para saber qué sitio se estaba procesando, el operador tenía que leer líneas y líneas de consola. Fatiga cognitiva pura.
Bloque 2
El insight clave: No necesitábamos un nuevo endpoint de estado en el backend. La información ya estaba viajando en el stream de logs hacia el frontend.
Así lo resolvimos con un enfoque minimalista y eficiente:
Bloque 3
• Señales visuales claras: Borde azul pulsante para procesos activos y verde sólido para completados. • Cero cambios en el backend: Implementamos un parser en el cliente que detecta el sitio actual analizando el flujo de logs en tiempo real. • Accesibilidad real: Soporte para 'prefers-reduced-motion' para evitar disparadores vestibulares en usuarios sensibles. • Persistencia inteligente: Uso de localStorage con un TTL de 24 horas para que el estado de 'completado' sea útil pero no eterno.
La lección aquí es clara: antes de añadir complejidad al servidor, mira si el flujo de datos actual ya contiene la respuesta.
Bloque 4
La visualización no es un 'adorno'; es una herramienta para reducir la carga mental del equipo técnico.
¿Prefieres optimizar el backend para tener datos estructurados o resolver el problema en el frontend para iterar más rápido?