StableUp

Proyecto final · 1.º DAW · STEM Granada

Tipo: Aplicación web full stack
Contexto: 3º Trimestre

1 / 4

Visión

Mantener un hábito cuesta. Empezar es fácil; lo difícil es seguir cuando nadie te obliga. StableUp nace de una idea sencilla: ¿y si cumplir tus objetivos tuviera la misma recompensa que avanzar en un juego?

Descripción

Para el proyecto final de 1.º de DAW nos dieron libertad total para construir la aplicación que quisiéramos. Yo elegí esta: una app que motiva a mejorar tus hábitos a través de un juego de coleccionables. Cada hábito que completas te da monedas y experiencia; con las monedas consigues caballos de distintas rarezas, y con tus caballos compites en carreras contra los de otros usuarios. Cuanto más constante eres, más fuerte es tu cuadra.

Es un proyecto full stack hecho a mano de principio a fin: diseñé el modelo de datos, construí la API REST en Java con Spring Boot y programé el frontend en JavaScript sin frameworks. Sin plantillas ni generadores: cada capa, cada endpoint y cada componente de la interfaz los escribí yo.

Diagrama UML de StableUp: Usuario, Hábito, Registro, Caballo, Carrera y ParticipacionCarrera con sus relaciones — Diagrama UML del modelo de datos. Un usuario tiene caballos y hábitos, cada hábito guarda un registro por día completado y los caballos compiten en carreras.

Lo que aprendí

Diseñar antes de programar
Empecé por el diagrama UML: usuarios, hábitos, registros, caballos y carreras, y cómo se relacionan. Tener el modelo claro desde el principio hizo que todo lo demás encajara.
Una arquitectura que escala
Separar controladores, servicios, repositorios y entidades me enseñó por qué cada capa debe hacer una sola cosa, y lo fácil que es cambiar una parte sin romper el resto.
Pensar en API
Diseñar una API REST con cinco recursos, sus rutas y sus respuestas, y probarla con Postman antes de tener interfaz, me obligó a pensar en el backend como un producto en sí mismo.
Equilibrar un juego
Las probabilidades del gacha, el multiplicador de las rachas y las recompensas de las carreras tenían que motivar sin romper la economía. Ajustar esos números fue tan importante como el código.

Cómo está hecho

El backend sigue una arquitectura por capas en la que cada una solo habla con la siguiente: controladores REST, servicios con la lógica de negocio (separados en interfaz e implementación), repositorios con Spring Data JPA y entidades mapeadas a tablas.

La API expone cinco recursos bajo /api/v1 (usuarios, hábitos, registros, caballos y carreras) con su CRUD completo y acciones propias como completar un hábito o iniciar una carrera. El modelo está documentado con un diagrama UML y JavaDoc, y la base de datos H2 se llena de datos de prueba al arrancar.

Tecnologías

Backend: Java 25Spring Boot 4Spring Data JPAHibernateH2Maven
Frontend: HTMLCSSJavaScriptBootstrap 5
Herramientas: GitPostmandraw.ioJavaDoc

Siguiente proyectoR&M Wiki →

Descripción

Diagrama UML del modelo de datos. Un usuario tiene caballos y hábitos, cada hábito guarda un registro por día completado y los caballos compiten en carreras.

Lo que aprendí

Diseñar antes de programar

Empecé por el diagrama UML: usuarios, hábitos, registros, caballos y carreras, y cómo se relacionan. Tener el modelo claro desde el principio hizo que todo lo demás encajara.

Una arquitectura que escala

Separar controladores, servicios, repositorios y entidades me enseñó por qué cada capa debe hacer una sola cosa, y lo fácil que es cambiar una parte sin romper el resto.

Pensar en API

Diseñar una API REST con cinco recursos, sus rutas y sus respuestas, y probarla con Postman antes de tener interfaz, me obligó a pensar en el backend como un producto en sí mismo.

Equilibrar un juego

Las probabilidades del gacha, el multiplicador de las rachas y las recompensas de las carreras tenían que motivar sin romper la economía. Ajustar esos números fue tan importante como el código.

Cómo está hecho