JCLDeveloper Portfolio
← Proyectos

Caso de estudio · Proyecto personal

Learning-OS

Learning-OS es una plataforma full-stack de aprendizaje técnico. Integra Angular, Spring Boot, PostgreSQL y Auth0, con despliegue mediante Docker Compose en Azure.

  • Java 25
  • Spring Boot 4
  • Angular 22
  • PostgreSQL 18
  • Flyway

Learning-OS — Presentación del proyecto

Learning-OS · Presentación del proyecto

Pantallas reales de Learning-OS ejecutado en local con un perfil de prueba; los diagramas de arquitectura y despliegue son visualizaciones. Música y efectos originales, sin narración.

Ver arquitecturaPantallas reales
01

Visión general

Una aplicación para organizar rutas de aprendizaje, cursos, evaluaciones y progreso, con backend Java, interfaz Angular, persistencia relacional y autenticación delegada.

Problema

Hacía falta una plataforma para organizar rutas de aprendizaje técnico, estructurar cursos y seguir el progreso de forma consistente.

Solución

Learning-OS integra contenido de aprendizaje, seguimiento, evaluaciones y funcionalidades de usuario, con persistencia relacional y autenticación delegada.

Objetivo El objetivo fue construir una aplicación completa —desde la API hasta el despliegue— para aplicar en un mismo sistema backend Java, persistencia relacional, autenticación y contenedores.

02

Funcionalidades

Implementadas y visibles en la aplicación real.

  • Rutas de aprendizaje
  • Cursos
  • Unidades de aprendizaje
  • Evaluaciones
  • Revisiones
  • Calendario
  • Marcadores
  • Búsqueda
  • Seguimiento de progreso
  • Frontend SPA que consume la API e inicia el inicio de sesión. Angular · TypeScript
  • Backend API REST con la lógica de negocio y la validación de tokens. Java · Spring Boot
  • Seguridad Identidad delegada en Auth0 y API protegida con tokens. Spring Security · Auth0 · OAuth 2.0 · OIDC · JWT · PKCE
  • Datos Persistencia relacional con esquema versionado por migraciones. PostgreSQL · Flyway
  • Infraestructura Servicios en contenedores dentro de una máquina virtual. Docker Compose · Nginx · Ubuntu · Azure VM
03

Arquitectura y seguridad

Diagrama del despliegue real. Cambia de vista o selecciona un componente para ver qué hace y con qué se conecta.

  1. El navegador solicita la aplicación por HTTPS y Nginx entrega el frontend Angular.
  2. Angular llama a la API REST; Nginx reenvía la petición a Spring Boot por la red interna.
  3. Spring Boot aplica la lógica de negocio y lee o escribe en PostgreSQL.
  4. La respuesta HTTP regresa por Nginx hasta el navegador.

Selecciona un componente para ver qué hace y con qué se conecta.

Decisiones técnicas

  • Frontend y backend separadosAngular se sirve como aplicación estática desde Nginx y la lógica vive en una API Spring Boot independiente. Cada capa se desarrolla, prueba y despliega por separado, comunicándose mediante contratos HTTP.
  • Persistencia relacionalRutas, cursos, unidades, evaluaciones y progreso están relacionados entre sí; PostgreSQL modela esas relaciones con integridad referencial. Flyway versiona el esquema para construir cada entorno de forma reproducible.
  • ContenerizaciónDocker Compose define Nginx, el backend y PostgreSQL como servicios. El mismo archivo describe el entorno local y el de la máquina virtual.
  • Restricción de puertosSolo Nginx publica puertos hacia Internet. El backend y PostgreSQL se comunican por la red interna de Docker.

Seguridad

  • Autenticación delegadaEl inicio de sesión se delega en Auth0 con OAuth 2.0 y OpenID Connect, así la aplicación no gestiona contraseñas directamente.
  • PKCE en la SPAAngular usa el flujo Authorization Code con PKCE, adecuado para aplicaciones que se ejecutan en el navegador.
  • API como servidor de recursosSpring Security valida la firma y los claims de cada JWT con las claves públicas de Auth0 antes de procesar la solicitud.
  • HTTPSNginx termina TLS con certificados de Let’s Encrypt: el tráfico entre el navegador y la aplicación viaja cifrado.
04

Calidad y evidencias

Resultados de las pruebas realizadas durante el despliegue del laboratorio. No representan métricas permanentes de disponibilidad ni un SLA.

  • 28Migraciones Flyway exitosasConstrucción del esquema de PostgreSQL durante el despliegue del laboratorio.Fuente: Registro de ejecución de Flyway.
  • 16/16Pruebas de humo aprobadasVerificación funcional posterior al despliegue en staging.Fuente: Resultado de la suite de pruebas de humo.
  • TLSHTTPS validadoCertificado de Let’s Encrypt servido por Nginx en el dominio de la VM.Fuente: Comprobación del certificado emitido.
  • 0Puertos públicos directos en backend y PostgreSQLAmbos servicios solo son accesibles por la red interna de Docker.Fuente: Revisión de los puertos publicados en la VM.
05

Galería y recursos

Capturas reales de Learning-OS ejecutado en local con un perfil de prueba sintético (sin datos personales).

Recursos y demostración

La demostración de Learning-OS está alojada en un laboratorio Azure que puede estar apagado para controlar costos. No se presenta como un servicio con disponibilidad garantizada.

Abrir la demo ↗ Tráiler vertical (9:16) ↗

Aprendizajes

  • Integrar OIDC entre una SPA y una API exige entender quién emite, transporta y valida cada token.
  • Versionar el esquema desde el inicio evita diferencias difíciles de rastrear entre entornos.
  • Un despliegue no está terminado hasta verificarlo con pruebas reproducibles.

Limitaciones

  • La VM de Azure se enciende bajo demanda, por lo que la demo tiene disponibilidad intermitente.
  • El despliegue usa una única máquina virtual: no hay redundancia ni escalado horizontal.
  • Las evidencias corresponden a una ejecución concreta del laboratorio.