PWA de finanzas personales: gastos, ingresos y objetivos de ahorro, con cola offline que se sincroniza sola
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.
api/auth.php — registro, login, logout y consulta del usuario
actual, con sesión por cookie de PHP.
api/categorias.php — categorías propias de gasto o ingreso, con
marca de recurrente.
api/transacciones.php — alta, listado filtrable y borrado.
Acepta la marca creado_offline.
api/objetivos.php — creación con importe y fecha límite, y
cambio de estado entre activo, completado y cancelado.
Tarjetas de resumen con ingresos, gastos y saldo.
Listado de transacciones filtrable por rango de fechas, tipo y búsqueda por texto.
Transacciones almacenadas en el navegador cuando no hay red, sincronizadas al recuperar la conexión.
Aviso legal, política de privacidad conforme al RGPD y la LOPDGDD, política de cookies y términos de uso.
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
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.
| Tabla | Contenido |
|---|---|
| usuarios | Cuentas con nombre, email y contraseña |
| categorias | Categorías propias de cada usuario, de tipo gasto o ingreso, con marca de recurrente |
| transacciones | Movimientos con tipo, categoría, fecha, importe, descripción, método de pago y marca de creado sin conexión |
| objetivos | Objetivos de ahorro con importe objetivo, fecha límite y estado |
creado_offline.app.js recorre la cola y envía cada transacción a
api/transacciones.php.api/config.php./api/ de la
caché: en una aplicación financiera, mostrar un saldo cacheado es peor que no
mostrar nada.
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.
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.
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.
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.
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.
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.