El servidor confirma la puja
La confirmación reside en el backend y STOMP distribuye los eventos en vivo. El broker conserva estado en memoria por instancia, una limitación del alcance de demostración.
CASO DE ESTUDIOMÓVIL Y BACKEND
QuickBid
Una subasta. Dos extremos conectados.
Proyecto · Colaborativo · demo
JavaSpring BootPostgreSQLSQLReact NativeReactTypeScriptWebSocket / STOMPDockerTesting
Visión general
Subastas móviles con pujas en tiempo real, conectando React Native y un backend Java.
Catálogo, consignaciones, cuentas y notificaciones completan el flujo de subasta. Proyecto colaborativo de demostración, con datos ficticios y pagos simulados.
Problema
Mantener la experiencia móvil alineada con las ofertas y los plazos que confirma el servidor.
Mi rol
Participé en el desarrollo colaborativo de la solución. Mis contribuciones al backend incluyen validación de límites y plazos de pujas, recuperación del historial reciente y pruebas de integración.
Arquitectura
React Native/TypeScript → REST y WebSocket/STOMP → servicios Spring Boot → PostgreSQL. JWT y refresh tokens gestionan la sesión; Flyway mantiene el esquema. El broker STOMP conserva estado en memoria por instancia.
Decisiones técnicas
Borradores locales, ofertas conectadas
Los borradores de consignación se guardan en el dispositivo. Las pujas requieren conexión y confirmación del servidor para mantener la oferta alineada con el estado de la subasta.
Desafíos y soluciones
La lógica de pujas valida los plazos de la subasta y recupera el historial reciente. El estado en memoria del broker y el almacenamiento local de archivos delimitan el alcance de la demo.
Resultados
Backend y cliente móvil integrados, con pujas confirmadas por servidor y eventos en tiempo real. Los pagos y los datos comerciales son de demostración.