Cuando tu aplicación ya almacena en caché los archivos estáticos como CSS, imágenes y fuentes, el siguiente paso es garantizar que los datos que provienen de servidores externos también estén disponibles sin conexión. Esto marca la diferencia entre una PWA funcional y una que deja al usuario con pantallas vacías al perder internet.
¿Cómo funciona el caché de requests dinámicos en Angular?
En una aplicación Angular con service worker, los archivos estáticos se agrupan dentro de los asset groups en el archivo de configuración. Sin embargo, las peticiones a APIs externas —como obtener productos de un servidor en Heroku— no se almacenan automáticamente. Al pasar a modo offline, los assets se muestran correctamente, pero la información dinámica desaparece [01:00].
Para resolver esto se utilizan los data groups, un nuevo bloque de configuración que permite definir reglas de caché específicas para URLs de APIs externas [02:07]. Al igual que los asset groups, los data groups son un array donde cada grupo recibe un nombre, como "API", y una lista de URLs que se desean almacenar.
¿Qué URLs debo incluir en mis data groups?
Puedes especificar exactamente qué endpoints cachear [03:25]. Si solo necesitas los productos, agregas la URL específica. Si quieres cubrir todo lo que provenga de un dominio, usas un comodín con doble asterisco. Esto es útil cuando manejas múltiples servicios o una arquitectura de microservicios.
- Revisa tus servicios en el módulo core para identificar cada endpoint.
- Puedes cachear selectivamente: productos sí, usuarios no.
- Verifica las variables de entorno para obtener la URL base correcta.
¿Qué opciones tiene el cacheConfig?
Dentro de cada data group se define un objeto cacheConfig con varias propiedades clave [05:02]:
- maxSize: número máximo de requests almacenados en caché. Si el usuario solicita el mismo endpoint más veces de las permitidas, se fuerza una petición real al servidor. Un valor típico es 3.
- maxAge: tiempo de vida del caché. Se configura con unidades como d para días, h para horas, m para minutos, s para segundos y u para milisegundos [06:15]. Lo habitual es usar minutos, horas o días.
- strategy: define la prioridad entre caché y red.
- timeout: tiempo de espera antes de pasar al plan alternativo [10:24].
¿Cuál es la diferencia entre freshness y performance?
Estas dos estrategias determinan el comportamiento del service worker al recibir una petición [08:00].
Performance prioriza el caché. Siempre busca primero en el almacenamiento local y solo acude a internet si no encuentra la información. Esto ofrece la experiencia más rápida para el usuario, ya que los datos se sirven de inmediato sin esperar respuesta del servidor.
Freshness funciona al revés: siempre intenta obtener datos frescos de internet, y solo recurre al caché cuando la red falla o es demasiado lenta. Es la opción recomendada cuando necesitas que el usuario vea información actualizada, como en un catálogo de productos que cambia frecuentemente [13:42].
El timeout complementa ambas estrategias. Define cuántos segundos esperar antes de cambiar al plan B. Un valor de dos segundos es razonable para la mayoría de los casos [10:50].
¿Cómo verificar que el caché dinámico funciona correctamente?
Después de configurar los data groups, es necesario compilar con ng build y hacer deploy al servidor de producción [09:30]. Al inspeccionar el Network del navegador, las peticiones que muestran origen service worker confirman que los datos se están sirviendo desde el caché.
Hay un detalle importante durante el desarrollo: el service worker puede quedarse con una versión antigua si no se gestiona correctamente. En la pestaña Application del navegador, activa la opción update on reload para forzar la descarga de la versión más reciente en cada recarga [14:50].
- Si un producto nunca fue visitado, no estará en caché.
- Solo los endpoints que el usuario ya consultó quedarán disponibles offline [16:22].
- Borrar el caché del service worker puede ser necesario mientras no implementes un sistema de actualizaciones automáticas.
Con la estrategia freshness y un timeout adecuado, tu aplicación puede seguir mostrando productos visitados incluso sin conexión, ofreciendo una experiencia robusta sin sacrificar la frescura de los datos. ¿Qué estrategia te parece más adecuada para tu proyecto?
