Angular 21 de Cero a Experto / HTTP y datos

Reto: la capa de datos de Mi Bolsillo con caché

Reto35 min60 XP

Vas a construir la columna vertebral de datos de "Mi Bolsillo": un servicio que lee y escribe gastos contra una "API", con una caché que ahorra peticiones e invalidación correcta tras cada mutación. Es el patrón profesional que evita tanto las peticiones de más como el bug de mostrar datos viejos. Hoy lo dejas listo con la lógica probada en vivo.

Reto

Servicio de datos con caché e invalidación

Media35 min60 XP(×2 sin mirar la solución)

Qué debes construir

Un RepositorioGastos que envuelva la "API" con caché:

Lecturas cacheadas: listar() devuelve de la caché si está fresca; si no, "pide al servidor", cachea con TTL y devuelve. Cuenta las peticiones reales.
Escrituras con invalidación: crear(gasto), actualizar(gasto) y eliminar(id) hacen la mutación e INVALIDAN la caché de la lista, para que la próxima lectura sea fresca.
Estadísticas: expón cuántas peticiones reales se hicieron y cuántas se sirvieron de caché, para demostrar el ahorro.

Reglas

La caché debe tener TTL (expiración por tiempo) además de invalidación por escritura.
Toda mutación (crear/actualizar/eliminar) invalida la caché de la lista.
Una lectura tras otra sin mutaciones no debe repetir la petición (mientras esté fresca).

35:00

Cuando estés listo, arranca el reloj.

El razonamiento. Una capa de datos profesional equilibra dos fuerzas opuestas: NO pedir de más (caché) pero NO mostrar datos viejos (invalidación). La caché con TTL cubre el caso de datos que cambian por su cuenta (caducan solos); la invalidación por escritura cubre el caso de datos que cambia el propio usuario (tras crear/editar/borrar, la caché de la lista deja de ser válida). El error clásico —cachear y olvidar invalidar— hace que el usuario agregue un gasto y no lo vea. Aquí, cada mutación invalida la lista, garantizando frescura. Esta es exactamente la lógica que httpResource y TanStack Query automatizan; construirla te hace entender qué hacen por dentro.

Qué observar:

Las lecturas 1-3: la primera pide al servidor (miss), las dos siguientes sirven de caché (hits) —una sola petición para tres lecturas—.
Al crear "Almuerzo", se invalida la caché de la lista.
La lectura 4 falla la caché (fue invalidada) → pide datos frescos que YA incluyen "Almuerzo". La 5 vuelve a servir de caché.
Stats finales: 2 peticiones reales para 5 lecturas. La caché ahorró 3 peticiones, y la invalidación garantizó que nunca vieras la lista sin el gasto nuevo.

En Angular real, ServidorFalso sería HttpClient, los métodos devolverían Observables, y podrías envolver todo con shareReplay o simplemente usar httpResource (que gestiona buena parte de esto). Pero la lógica de caché + invalidación que acabas de construir es la que decide si tu app es rápida y correcta —o rápida y con datos viejos—.

Qué sigue

Terminaste el módulo de datos: tu app puede leer y escribir contra un backend, con estados, interceptores y caché. A medida que la app crece, ese estado —el que viene del servidor y el propio de la UI— necesita organizarse a gran escala. El próximo módulo es el estado a gran escala: stores de features, NgRx SignalStore, arquitectura por features y el patrón facade. Cómo estructurar el estado de una app que vive años.