Todo comenzó con un plan clásico. Estaba diseñando el “Proyecto Fénix”, un sistema para gestionar solicitudes académicas. La arquitectura era sólida y predecible: un backend robusto en Spring Boot que manejaría toda la lógica de negocio, la seguridad y la persistencia de datos, y un frontend ágil en JavaScript puro para consumir la API y ofrecer una experiencia de usuario limpia.
Sobre el papel, era perfecto. En la práctica, se convirtió en un cuello de botella.
El Ritmo Roto de la Dependencia
El núcleo del sistema residía en un motor de reglas de negocio increíblemente complejo. Una solicitud no era simplemente “aprobada” o “rechazada”; pasaba por una cascada de validaciones. ¿El periodo de solicitud está activo? ¿El usuario ya tiene solicitudes en proceso? ¿Su estatus académico lo permite? ¿Tiene bloqueos administrativos? Cada motivo de solicitud—conflicto de horario, situación laboral, problemas de salud—desencadenaba un árbol de decisiones distinto que dependía del semestre del usuario, su promedio y otros factores.
Mi trabajo en el frontend se veía constantemente interrumpido. Implementaba un formulario, pero necesitaba el endpoint de “elegibilidad” para poder habilitar el botón de envío. Diseñaba la vista de “mis solicitudes”, pero la estructura de datos final aún se estaba debatiendo en el backend. Cada pequeño ajuste en las reglas de negocio significaba esperar a que el backend se actualizara, se desplegara y estuviera disponible para mí.
El desarrollo se sentía como una carrera de relevos donde mi compañero de equipo se detenía a cada rato a atarse los cordones. No era culpa de nadie; era la naturaleza de un sistema acoplado en sus fases iniciales. Pero la frustración era real y el avance, lento.
Fue en medio de esa lentitud que me hice una pregunta radical: ¿Y si el frontend no tuviera que esperar? ¿Y si, en lugar de simular respuestas de API, pudiera simular el backend completo?
Construyendo un Cerebro Digital en el Navegador
La idea era más profunda que simplemente devolver un JSON estático. Decidí portar la lógica de negocio completa—el ElegibilidadService y el EvaluacionSolicitudService que vivían en Java—a un archivo JavaScript. Mi objetivo era crear una réplica funcional del motor de decisiones que pudiera ejecutarse íntegramente en el navegador.
Comencé por definir un contrato de API claro y establecí que ese sería nuestro pacto inmutable entre el front y el back. Luego, me sumergí en la tarea de replicación.
- Una Base de Datos en la Memoria del Navegador: Usé
localStoragecomo una base de datos efímera. Cada vez que un usuario “enviaba” una solicitud a través del prototipo, esta se guardaba en el almacenamiento local, permitiendo persistencia entre sesiones y simulando un historial real. - El Motor de Reglas en JavaScript: Traduje cada
if,else ifyswitchde la lógica de negocio de Java a funciones de JavaScript. La lógica determinista que decidía el destino de una solicitud ahora vivía y respiraba en el cliente. - Una API Estática: Creé un objeto global, una especie de
StaticAPI, que exponía métodos con nombres idénticos a los endpoints REST:solicitar(),consultar(),cancelar(). El resto de mi código frontend interactuaba con este objeto sin saber que no estaba haciendo una llamadafetchreal. Esto fue clave: el día que el backend real estuviera listo, solo tendría que reemplazar el objetoStaticAPIpor el cliente HTTP real, sin tocar una sola línea de la lógica de la interfaz.
El resultado fue un mock que no se sentía como un mock. Era un gemelo digital del backend, un entorno de desarrollo autocontenido que me dio una libertad sin precedentes.
Las Ventajas Inesperadas de la Autonomía
Lo que comenzó como una solución a un problema de velocidad se transformó en una ventaja estratégica fundamental.
Primero, la velocidad de desarrollo se disparó. Podía construir y probar flujos de usuario completos de principio a fin sin dependencias externas. Podía refinar la interfaz, animar transiciones y pulir la experiencia del usuario basándome en respuestas lógicas instantáneas y coherentes.
Segundo, las pruebas de usuario se volvieron increíblemente valiosas. En lugar de mostrar a los interesados maquetas estáticas o prototipos que solo seguían un camino feliz, podía entregarles una aplicación completamente funcional. Podían probar casos límite, explorar diferentes escenarios y, como resultado, su feedback era sobre la experiencia real. Esto nos ayudó a descubrir fallos y ambigüedades en las propias reglas de negocio mucho antes de que se escribiera la versión final en el backend.
Finalmente, logré un desacoplamiento real. El equipo de backend podía ahora centrarse en la seguridad, la escalabilidad y la optimización de su lado, con la tranquilidad de que el contrato de la API era la única zona de contacto. El mock inteligente se convirtió en la documentación viviente y en la fuente de verdad para el desarrollo del frontend.
Cuando finalmente llegó el momento de integrar el backend real, el proceso fue sorprendentemente anticlimático. Simplemente reemplacé el proveedor de datos estático por el cliente HTTP. Todo funcionó a la primera. No hubo sorpresas, ni reajustes de última hora. El trabajo duro ya estaba hecho.
A veces, la mejor manera de avanzar juntos es encontrar una forma inteligente de trabajar por separado. Construir esa réplica del cerebro del sistema en el navegador no fue un atajo; fue una inversión que me permitió crear una mejor interfaz, más rápido y con menos fricción. Fue la prueba de que, con el enfoque correcto, el frontend no tiene por qué ser solo un consumidor pasivo de datos, sino un socio proactivo en la construcción de la lógica del producto.