💶 Eurcontroller

Escala del Proyecto

Descripción General

Una aplicación de gastos solo funciona si registras el gasto en el momento de hacerlo. Si lo dejas para la noche, no lo apuntas. Y el momento de hacerlo es a menudo en un sitio sin cobertura: un sótano, un supermercado, el metro.

Eurcontroller resuelve eso con una cola offline. Si no hay conexión, la transacción se guarda en el navegador y se marca como creada sin red; cuando la conexión vuelve, se sincroniza automáticamente contra la API. El usuario no se entera ni tiene que hacer nada.

Por lo demás es una aplicación de finanzas personales completa: categorías propias de gasto e ingreso, transacciones con fecha, importe, descripción y método de pago, objetivos de ahorro con importe y fecha límite, y un dashboard con ingresos, gastos y saldo. Incluye además las cuatro páginas legales adaptadas al RGPD.

Tecnologías Utilizadas

Módulos y API

Arquitectura

Aplicación de una sola página en index.html que contiene todas las vistas — autenticación, dashboard, transacciones, categorías y objetivos — con app.js gestionando la navegación, las llamadas a la API, la cola offline y el registro del service worker. El backend es una API PHP con un fichero por recurso.

El detalle importante del service worker es que cachea los recursos estáticos con estrategia cache-first pero excluye explícitamente las rutas /api/: cachear respuestas de la API en una aplicación de finanzas sería mostrar saldos desactualizados como si fueran reales.

Eurcontroller/
├── index.html             # SPA con todas las vistas
├── app.js                 # API, cola offline, service worker
├── styles.css
├── manifest.json          # instalable, modo standalone
├── service-worker.js      # cache-first, excluye /api/
├── schema.sql
├── api/
│   ├── config.php         # conexión PDO y helpers
│   ├── auth.php
│   ├── transacciones.php
│   ├── categorias.php
│   └── objetivos.php
└── legal/                  # 4 documentos RGPD

Base de Datos

4 tablas, el mínimo necesario. El modelo separa categorías de transacciones para que el usuario defina su propia taxonomía en lugar de aceptar una lista impuesta.

Cómo Funciona la Cola Offline

1. Registro del gasto: el usuario añade la transacción desde el móvil, con o sin cobertura.
2. Detección de red: si la petición a la API falla por falta de conexión, no se pierde el dato.
3. Encolado local: la transacción se guarda en el navegador marcada con creado_offline.
4. Uso normal: la aplicación sigue funcionando y mostrando las transacciones pendientes de enviar.
5. Recuperación de la conexión: al volver la red, app.js recorre la cola y envía cada transacción a api/transacciones.php.
6. Confirmación: las transacciones sincronizadas dejan de estar en la cola y pasan a formar parte del histórico del servidor.

Seguridad Implementada

• Autenticación por sesión de PHP con cookie; todos los endpoints validan el usuario antes de devolver datos.
• Contraseñas cifradas en el registro, nunca almacenadas en claro.
• Acceso a base de datos mediante PDO con sentencias preparadas.
• Credenciales de base de datos aisladas en api/config.php.
• El service worker excluye las rutas /api/ de la caché: en una aplicación financiera, mostrar un saldo cacheado es peor que no mostrar nada.
• Cada usuario solo accede a sus propias categorías, transacciones y objetivos.
• Textos legales conforme al RGPD y la LOPDGDD, con política de cookies limitada a las técnicas y de preferencias.

Retos Técnicos y Decisiones de Diseño

Una cola offline es más que un try/catch

Guardar el gasto cuando falla la petición es la parte fácil. Lo complicado es el resto: que el usuario vea qué está pendiente, que la transacción no se duplique si la petición sí había llegado, y que la sincronización se dispare sola al recuperar la red. La marca creado_offline viaja hasta la base de datos precisamente para poder distinguir esos casos.

No cachear nunca la API

La estrategia cache-first del service worker es perfecta para el HTML, el CSS y el JavaScript, y desastrosa para los datos: enseñar un saldo de hace tres días como si fuera el actual es peor que un error de red. La exclusión explícita de /api/ es la decisión técnica más importante del proyecto.

Cuatro tablas y ni una más

Es tentador añadir presupuestos, cuentas múltiples, divisas y etiquetas. Pero una aplicación de gastos se abandona por fricción, no por falta de funciones. Cuatro tablas y un formulario corto es lo que hace que el gasto se registre en el momento.

Las páginas legales desde el principio

Una aplicación que guarda datos financieros de personas necesita aviso legal, política de privacidad, política de cookies y términos de uso. Están incluidas como plantillas con los campos entre corchetes pendientes de rellenar, y el README avisa de que hay que completarlos antes de publicar.

Mi Rol

Desarrollador full stack — autor único.

Modelo de datos, API por recurso, frontend de una página, mecanismo de cola offline y sincronización, configuración de la PWA y redacción de los cuatro documentos legales.

Estado del Proyecto

Aplicación funcional e instalable como PWA, con modo standalone. Los textos legales son plantillas que requieren completar los datos del titular antes de publicar en producción.

Código y Enlaces

El repositorio incluye SECURITY.md y CODE_OF_CONDUCT.md.