Lo que aprendí rompiendo mi app en un concierto real 🎸
Muchos desarrolladores creemos que si funciona en localhost, el código está listo. Pero el mundo real es caótico y no perdona. Llevo dos meses con Fretlist y me he topado con el muro de la realidad: esos bugs que ningun
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
- Muchos desarrolladores creemos que si funciona en localhost, el código está listo. Pero el mundo real es caótico y no perdona.
- Llevo dos meses con Fretlist y me he topado con el muro de la realidad: esos bugs que ninguna suite de tests detecta, pero que un usuario en vivo encuentra en segundos.
- El insight es claro: la arquitectura debe diseñarse para el fallo, no para el escenario ideal.
- Estos son los 3 aprendizajes técnicos más costosos:
Bloque 1
Muchos desarrolladores creemos que si funciona en localhost, el código está listo. Pero el mundo real es caótico y no perdona.
Llevo dos meses con Fretlist y me he topado con el muro de la realidad: esos bugs que ninguna suite de tests detecta, pero que un usuario en vivo encuentra en segundos.
Bloque 2
El insight es claro: la arquitectura debe diseñarse para el fallo, no para el escenario ideal.
Estos son los 3 aprendizajes técnicos más costosos:
Bloque 3
• Race Conditions en Auth: Tenía middleware y la capa de datos refrescando la sesión simultáneamente, pisando los tokens. La solución fue arquitectónica: separar totalmente el cliente de datos del middleware para eliminar la contención.
• El engaño del WiFi: Mi app confiaba en el estado "conectado" del navegador. En un concierto, el tablet se unió al WiFi de la consola (sin internet) y la app colapsó al no tener fallback local. Ahora valido reachability real, no solo señal.
Bloque 4
• El costo del "Free Tier": Vercel Hobby ponía la app a dormir. Googlebot llegaba, encontraba un cold start lento y abandonaba. Perdí dos meses de indexación por intentar ahorrar unos dólares en infraestructura básica.
Mi conclusión como Tech Lead: No ignores la infraestructura "poco sexy" (auth, indexing, backups). Hazlo en la semana uno, o pagarás el precio en la semana diez.
Bloque 5
Construye para personas reales en entornos imperfectos, no para un mercado teórico.
¿Cómo gestionan ustedes la validación de conectividad real y el manejo de estados offline en sus arquitecturas?