---

---

Ahora resulta que si era buena opción jajaja

Hace unos años, en foros, conferencias y hasta en simples pull requests, era casi una herejía sugerir que algo del viejo mundo del software monolítico aún tenía valor. Cualquiera que defendiera patrones o prácticas asociadas a arquitecturas tradicionales era mirado con desdén, como si estuviera proponiendo volver a escribir código en COBOL o a usar disquetes para respaldar bases de datos.

Se decía, con tono de superioridad técnica, que el futuro estaba en arquitecturas descentralizadas, en microservicios, en clientes ricos que gestionaban su propio estado, y en dejar al servidor lo más “tonto” posible. El mantra era simple: el frontend inteligente, el backend minimalista. Y con eso, se entronizó la idea de que persistir información sensible en el lado del cliente —ya sea en localStorage, sessionStorage o incluso en cookies accesibles desde JavaScript— era no solo aceptable, sino moderno, eficiente y “a la vanguardia”.

Pero el tiempo, ese juez implacable, ha ido develando lo que muchos sabíamos en silencio: el navegador, por diseño, no es un lugar seguro para guardar credenciales, tokens de sesión ni datos sensibles. Nunca lo fue. Y sin embargo, durante años, vimos cómo equipos enteros construían arquitecturas críticas confiando en que el cliente era un entorno confiable. Se usaban JWT almacenados en el localStorage como si fueran certificados de nacimiento digital, ignorando que cualquier script malicioso, cualquier inyección XSS, podía robarlos en cuestión de milisegundos.

Y ahora, con una sonrisa irónica del destino, la industria vuelve —en silencio, sin pedir disculpas— a lo que antes se despreciaba: la sesión gestionada íntegramente en el servidor. Hoy, las buenas prácticas de seguridad recomiendan, casi como dogma, el uso de cookies HTTP-only, firmadas, con SameSite y Secure, que jamás tocan el entorno de JavaScript. Es decir, exactamente lo que hacían las aplicaciones monolíticas de los 2000: enviar un identificador de sesión al cliente, pero sin exponer ningún dato real, y gestionar todo el estado crítico en el backend.

¿No es irónico? Lo que ayer se ridiculizaba como “arcaico” o “limitado” es hoy el estándar de seguridad recomendado por OWASP, por los equipos de ciberseguridad de las grandes empresas y por los frameworks más modernos. Lo que antes se llamaba “falta de escalabilidad” ahora se reconoce como “defensa en profundidad”. Y lo que algunos llamaban “falta de visión” era, en realidad, sentido común.

Claro, no se trata de decir que los monolitos eran perfectos ni que los microservicios son un error. La tecnología evoluciona, y con ella, los paradigmas. Pero sí hay una lección incómoda aquí: la arrogancia técnica suele tener fecha de vencimiento. Y esa fecha suele llegar cuando la teoría se estrella contra la realidad de los ataques reales, los reportes de vulnerabilidades y los incidentes de seguridad.

Durante años, muchos de los que defendíamos la prudencia fuimos tildados de “resistentes al cambio”, de “atrapados en el pasado” o de “incapaces de entender la nube”. Se nos dijo que estábamos frenando la innovación. Pero innovar no significa ignorar los fundamentos. Tampoco significa sacrificar la seguridad en aras de la conveniencia del frontend.

Hoy, cuando se diseña una aplicación segura, se prioriza que el menor número posible de datos sensibles salgan del servidor. Se evita confiar en el cliente, y se entiende que el navegador es un entorno hostil, no un aliado. Es una postura que suena “anticuada” si la escuchas en 2016… pero es sentido común si la lees en un manual de 2025.

Y ahí está la lección más amplia: no todo lo nuevo es necesariamente mejor. A veces, lo que parece progreso es solo una vuelta al punto de partida, disfrazado con otro nombre, otro framework y otra terminología de moda. El ciclo se repite: se abandona una práctica por considerarla obsoleta, se cometen errores en su reemplazo, y luego se regresa a ella, pero ahora con más humildad y con la etiqueta de “best practice”.

Esto no es una crítica al cambio. Al contrario: celebro que la industria aprenda, se corrija y evolucione. Pero sí es una invitación a no confundir novedad con sabiduría. A no menospreciar lo que funcionaba bien solo porque alguien puso una pegatina de “legacy” encima. Y sobre todo, a escuchar con más respeto a quienes, desde la experiencia o desde la cautela, plantean dudas frente al ímpetu de lo “disruptivo”.

Porque al final del día, la tecnología no avanza en línea recta. Avanza en espiral. Y a veces, lo que parece un retroceso es en realidad un paso más consciente, más maduro, más seguro.

Y sí, río un poco. No por maldad, sino por alivio. Porque quienes dijimos “cuidado” no estábamos equivocados. Solo estábamos adelantados… o quizás simplemente enraizados en principios que nunca debieron olvidarse.

#DesarrolloSoftware #SeguridadWeb #ArquitecturaDeSoftware #IngenieríaDeSoftware #TechDebate #Frontend #Backend #Ciberseguridad #MonolitosVsMicroservicios #SentidoComúnTécnico