Defender el backend completo

Proyecto compartido. En el taller de Intermodular que abre esta semana has trabajado defender el producto y el proceso sobre la misma versión. En Servidor continúas la implementación del mismo producto.

Se explica

25 minutos · explicación y demostración

La versión final ya está preparada y documentada. Hoy defenderás las decisiones del backend con demostraciones sobre el mismo commit. La memoria técnica conecta requisito, implementación y evidencia para que la evaluación no dependa de una explicación de memoria.

La defensa se coordina con Intermodular 26: se hace una sola demostración y cada módulo aplica sus criterios. Relaciona las decisiones técnicas con el balance final del proyecto y reutiliza las comprobaciones de Intermodular.

La prueba definitiva: La Defensa Técnica

Llegar a la Sesión 52 significa que has completado el viaje completo: desde las primeras peticiones HTTP en la UD1 hasta un sistema empresarial complejo, seguro, observable y conectado.

En el mundo profesional y académico, el valor de un ingeniero se demuestra en la defensa de sus decisiones:

• Un comercial habla de lo atractiva que es la interfaz.
• Un ingeniero de backend explica por qué utilizó un tipo NUMERIC(12,2) para evitar pérdidas de precisión en dinero, cómo configuró un timeout de 2 segundos en RestClient para evitar el agotamiento de hilos en Tomcat, y cómo una política CORS bien diseñada protege a sus usuarios.

Estructura de la Defensa Técnica (15 minutos)

Distribuye tu exposición con rigor profesional siguiendo este minutaje:

1. 0–3 min: Arquitectura, modelo relacional y decisiones de diseño
2. 3–8 min: Demostración en vivo en Bruno (Happy Path y Casos Límite)
3. 8–12 min: Seguridad RBAC/ABAC, Resiliencia y Observabilidad (Logs MDC)
4. 12–15 min: Deuda técnica, límites honestos y turno de preguntas

1. Bloque 1: Arquitectura y Modelo (3 minutos):
   • Muestra el diagrama de agregados (Proyecto, Tarea, Incidencia, Usuario).
   • Justifica la elección de tipos de datos (BIGINT IDENTITY, NUMERIC(12,2) para dinero) y la estrategia de esquemas versionados con ddl-auto=validate.
2. Bloque 2: Demostración en vivo en Bruno (5 minutos):
   • No uses diapositivas estáticas: abre Bruno y ejecuta peticiones reales.
   • Demuestra el camino feliz: autenticación JWT → creación de proyecto → respuesta 201 Created con cabecera Location.
   • Demuestra la robustez ante errores de negocio: intenta sobrepasar el presupuesto total de un proyecto y muestra el error 400 Bad Request o intenta cerrar con tareas pendientes mostrando el código 409 Conflict.
3. Bloque 3: Seguridad, Resiliencia y Observabilidad (4 minutos):
   • Muestra la matriz de permisos: autentícate con un rol no autorizado y muestra el 403 Forbidden.
   • Demuestra la degradación elegante: simula la desconexión de la red de Open-Meteo y enseña cómo la incidencia se guarda con aviso en lugar de romper con un 500.
   • Abre la terminal y enseña el archivo de logs: filtra por un X-Correlation-ID y demuestra la trazabilidad de la llamada.
4. Bloque 4: Límites y Compromisos de Ingeniería (3 minutos):
   • Explica los compromisos adquiridos (Trade-offs): qué optimizaste (velocidad de desarrollo, consistencia) y qué quedó como deuda técnica para una futura versión 2.0 (ej: migrar a Transactional Outbox para webhooks).

Se trabaja

140 minutos · implementación guiada sobre el proyecto propio

Paso 1 · Retomar el proyecto y preparar la comprobación

1. Abre el repositorio, la aplicación y la documentación de la versión final. Comprueba que todos corresponden al commit que vas a presentar.
2. Prepara un recorrido permitido, uno rechazado, una regla transaccional y una prueba automatizada. Localiza sus clases antes del ensayo.
3. Elige también un fallo que hayas corregido y conserva la evidencia que explica causa, cambio y comprobación.

Paso 2 · Preparación del guion y simulación de preguntas

Las cuatro preguntas clásicas que formulará el tribunal y cómo argumentarlas:

| «Me dices que tienes un 80 % de cobertura. ¿Qué parte del sistema es la que peor está probada?» | “La cobertura de líneas es engañosa. Nuestro punto más débil es la concurrencia sobre el presupuesto: los tests la comprueban en secuencia, no con hilos simultáneos. Lo detectamos en la sesión 51 y está anotado como riesgo abierto en la memoria.” | | «Enséñame dónde está escrita la regla de que un operario no puede cerrar un proyecto.» | Aquí no se contesta con palabras: se abre el código. “Está en dos sitios, y a propósito: el @PreAuthorize de este método y el test operario_noPuedeCerrarProyecto que lo vigila. Si alguien quita la anotación, la suite se pone en rojo.” | | «¿Qué harías distinto si empezaras hoy?» | La peor respuesta es «nada». “Habría sacado el esquema a Flyway desde el primer día en vez de a schema.sql: lo hicimos en la sesión 47 y ya arrastrábamos datos que hubo que migrar a mano.” |

Escribe tu guion en una tabla de tres columnas. La tercera es la que decide si apruebas:

Cualquier fila cuya tercera columna quede vacía es una afirmación sin prueba. O le buscas evidencia, o la quitas del guion: en una defensa técnica, lo que no se enseña no cuenta.

Una demostración se cae por logística, no por código. Prepara esto antes del día:

1. Una carpeta en tu cliente HTTP llamada defensa, con las peticiones en el orden exacto del guion y numeradas: 01-login-admin, 02-crear-proyecto, 03-crear-tarea…

2. Variables de entorno configuradas para que el token se guarde solo tras el login. Nadie debe verte copiando y pegando un JWT de 300 caracteres en directo.

3. Un data.sql con datos de demostración creíbles: proyectos con nombres reales, no aaa ni test1.

4. Una segunda ventana de terminal con los logs ya corriendo, y el tamaño de letra subido para que se lea desde el fondo del aula.

5. Un plan B: si la red del centro falla, tu degradación elegante hará que la demostración siga funcionando. Practica contando eso como una virtud, porque lo es.

6. Intercambia proyectos con otro equipo.

7. Cada uno prepara cinco preguntas sobre el proyecto ajeno, mirando el código, no la memoria.

8. Realiza la defensa completa cronometrada, con turno de preguntas al final.

9. Anota las preguntas que no supiste contestar: esa lista es tu única tarea pendiente hasta el día de la defensa.

Paso 3 · Ensayo general cronometrado

Prepara la versión que has entregado con su configuración de demostración y datos ficticios. Comprueba acceso, base de datos y proveedor antes de iniciar el cronómetro. Si utilizas PowerShell, sigue el log con Get-Content logs/aplicacion.log -Tail 30 -Wait; en Linux/macOS, con tail -f. Ensaya los bloques del guion con margen para preguntas. Si cambia algún dato o estado durante la demostración, reconstruye el escenario con la colección antes del siguiente ensayo.

1. Prepara el entorno:
   • Arranca Docker con PostgreSQL limpio.
   • Levanta el backend con ./mvnw spring-boot:run.
   • Abre Bruno con la colección ordenada de la defensa.
   • Abre la terminal con tail -f logs/aplicacion.log.
2. Ejecuta el ensayo con cronómetro en mano:
   • Comprueba que completas la exposición en exactamente 12 minutos, dejando 3 minutos limpios para preguntas.
   • Si alguna petición falla en vivo, no entres en pánico: copia el correlationId del JSON de error, búscalo en la terminal de logs y explica al tribunal con total calma qué regla de validación o seguridad ha actuado. Eso demuestra madurez de ingeniería.

Paso 4 · Si algo se tuerce en directo

Paso 5 · Redactar la Memoria Técnica de la Defensa

Prepara una explicación técnica del proyecto. Para cada apartado sigue requisito → decisión → archivo o método → prueba y resultado; enlaza los registros de sesiones cuando contengan la evidencia para no volver a copiarla. Añade el commit y la URL de la versión demostrada, más las limitaciones conocidas. La explicación debe corresponder al código y a las pruebas que realmente funcionan.

1. Resumen ejecutivo: qué resuelve el sistema y con qué tecnologías, en una página.
2. Modelo de datos: diagrama entidad-relación y justificación del esquema SQL, tipo por tipo en los campos delicados (dinero, fechas, estados).
3. Contrato de la API: matriz de seguridad RBAC/ABAC frente a la lista de endpoints, con el openapi.json de la sesión 51 como anexo.
4. Resiliencia: qué servicios externos consumes, con qué timeouts, qué pasa cuando fallan y cómo lo has comprobado.
5. Estrategia de pruebas: qué cubre la suite, qué no cubre, y el dato de la sesión 51 sobre cuántos fallos encontró la pasada manual que los tests no vieron.
6. Deuda técnica: inventario honesto de lo que dejarías distinto, ordenado por lo que más duele. Este apartado, bien hecho, vale más que cualquier otro: es el que demuestra que sabes juzgar tu propio trabajo.
7. Trazabilidad del curso: una tabla final que asocie cada capacidad del sistema con la unidad donde la aprendiste. Es tu propio índice de lo que sabes hacer, y es lo que te llevas del módulo.

Cómo saber que lo has terminado

Has completado la defensa entera dentro del tiempo, con la demostración en vivo funcionando de principio a fin; cada afirmación del guion tiene una evidencia que la acompaña; sabes contestar las cinco preguntas que te hizo el equipo con el que ensayaste; y la memoria incluye un apartado de límites que no rebaja lo que hiciste, sino que lo sitúa.

Paso 6 · Comprobar y registrar el resultado del proyecto

1. Ensaya la demostración y explica el camino de una petición desde el cliente hasta el dato persistido, incluyendo identidad y reglas.
2. Entrega la memoria y los enlaces dentro del repositorio; deben permitir revisar los mismos resultados aunque se termine la demostración en clase.

Ampliación si has completado el trabajo

Primero termina y verifica los pasos anteriores. Estos retos profundizan en el mismo contenido; no sustituyen la entrega ni obligan a iniciar otro proyecto.

Reto · Automatización de la demo con Newman o Bruno CLI

En lugar de pulsar las peticiones una a una en la interfaz gráfica durante la defensa, automatiza la ejecución de toda la suite de pruebas desde la línea de comandos:

1. Instala el CLI de Bruno (@usebruno/cli) o utiliza Newman.
2. Ejecuta la colección completa por consola: bru run --env local
3. Muestra al tribunal cómo se ejecutan 30 peticiones secuenciales con aserciones automatizadas de códigos HTTP, cabeceras y esquemas JSON en menos de 5 segundos.

Ver respuestas

1 · Porque demuestra de forma irrefutable que el sistema está vivo, que el código compila, que la base de datos persiste datos reales y que la aplicación responde a las reglas de negocio acordadas.

2 · Manteniendo la calma, leyendo el código de estado devuelto, acudiendo a los logs mediante el correlationId e interpretando con fundamento qué ha ocurrido; depurar un fallo en vivo con soltura transmite enorme competencia técnica.

3 · Porque ningún software real es perfecto; demostrar que eres consciente de los cuellos de botella y que sabes cómo resolverlos en una siguiente versión refleja pensamiento crítico y madurez profesional.

4 · La integridad de los datos (persistencia transaccional en PostgreSQL), la seguridad (autenticación y autorización RBAC/ABAC) y la resiliencia (observabilidad, timeouts y degradación elegante ante fallos externos).

Cierre

15 minutos · resultado comprobable y explicación individual

Al terminar la sesión:

Se evalúan individualmente comprensión, implementación y verificación del backend; Intermodular utiliza sus propias evidencias del flujo de trabajo.

Cada integrante explica una decisión del código apoyándose en una de las comprobaciones realizadas.