Saltar a contenido

ADR-001 — Stack fijado: Java 21, Spring Boot 4.1.1, SQL Server 2022, React 19 en un jar único

Status: accepted (discovery Q4 y Q12, 2026-09-03)

Contexto

BeneficiosCenter necesita persistir configuración (tipos de cliente, sucursales, beneficios, usuarios) y auditoría, y desplegarse en la infraestructura del primer cliente (Supermercados DINO, Córdoba), que ya opera SQL Server. La ruta caliente no depende de la base: resuelve desde un snapshot en memoria (ADR-002).

El equipo opera el Sistema de Premios con Spring Boot 4.1.1, SQL Server, Flyway, jar único con la SPA embebida, config externa al jar, servicio Windows y Caddy como TLS y reverse proxy. Ese proyecto usa Vite 5 y React 18, que ya no reciben parches: la consola nueva arranca en Vite 8 y React 19 portando componentes, no el package.json.

Alternativas

  • A) SQL Server 2022 + jar único Spring Boot 4.1.1 con consola embebida. Soporte: SQL Server mainstream hasta 2028-01-12; Spring Boot 4.1 OSS hasta 2027-07-31. Costo: reuso casi total de Premios.
  • B) PostgreSQL 17 + jar único. Motor sin licencia y con ventana larga, pero DINO no lo administra hoy. Costo operativo nuevo para el cliente.
  • C) Backend y frontend desplegados por separado. Más piezas que operar sin beneficio para un solo cliente.

Decisión

Alternativa A.

  • JDK Temurin 21 LTS, soporte al menos hasta 2029-12.
  • Spring Boot 4.1.1, última estable al 2026-09-03. OSS hasta 2027-07-31.
  • SQL Server 2022 con migraciones Flyway. Mainstream hasta 2028-01-12.
  • Node 24 LTS solo para construir la consola; no corre en producción.
  • Vite 8.x y React 19.x, TypeScript 5.x, shadcn sobre Tailwind, react-query 5, zustand 5, react-hook-form con zod.
  • Un único jar Spring Boot que expone la API de resolución, la API de administración y la consola compilada. Configuración operativa fuera del jar. TLS y exposición pública a cargo de Caddy o equivalente, nunca del jar.
  • Política de upgrade: el salto de Spring Boot 4.1 a la línea siguiente se agenda antes de 2027-07-31. Ninguna dependencia nueva entra sin aprobación explícita.

Razones

  • Reuso directo del pipeline, scripts de servicio y conocimiento operativo del Sistema de Premios.
  • La base es punto de falla solo para administración y auditoría, no para responder al gateway.
  • Un solo artefacto para versionar y desplegar; la consola y la API siempre van en la misma versión.

Consecuencias

  • ✅ Ventanas de soporte que cubren la operación hasta 2027 sin tocar nada, y hasta 2028 con un solo upgrade de Spring Boot.
  • ⚠️ El upgrade de Spring Boot queda en el calendario para el primer semestre de 2027.
  • ⚠️ Cambiar de motor de base más adelante exige revisar migraciones y tipos.

Plan de implementación

  • backend/pom.xml: parent spring-boot-starter-parent 4.1.1; spring-boot-starter-web, -data-jpa, -validation, -security, -actuator, mssql-jdbc, flyway-sqlserver, JaCoCo, Checkstyle, PMD, SpotBugs con FindSecBugs.
  • Config externa al jar; fail-fast si falta (INV-O04).
  • Build de la consola copiado a static/gestor/ en el empaquetado.
  • com.h2database:h2 en scope test, MODE=MSSQLServer, para la suite rápida sin Docker; el perfil it-sqlserver valida contra SQL Server real.