# PWA Update-Strategie Wiederverwendbare Strategie für Fränkys PWAs — damit Nutzer:innen **ohne Cache leeren** immer die aktuelle Version sehen. > Gitea-Wiki: manuell anlegen unter [PWA-Update-Strategie](https://gitea.schwenk.online/froxxxy/takeyourmeds/wiki/_pages) (MCP-Token hatte keine Wiki-Schreibrechte). ## Warum? - Viele Nutzer:innen wissen nicht, was „Cache leeren" bedeutet (besonders auf dem Handy / als installierte PWA). - Service Worker können alte Dateien **monatelang** vorhalten — ein Deploy reicht nicht. - Ziel: Updates **sichtbar und kontrolliert** (Banner + Reload), nicht stilles Veralten. ## Drei Ebenen (Tiers) ### Tier 1 — Service Worker & Client | Element | Strategie | |---------|-----------| | `sw.js` | Nicht vom SW intercepten; Server: `Cache-Control: no-cache` | | `index.html` | Network-first | | Unversioniertes JS/CSS | Network-first | | Cache-Name | Pro Build: `tym-v{version}-{buildHash}` | | `version.json` | Network-only im SW; Client-Check beim Start/Focus | | Update-Banner | `buildHash` ≠ `meta app-build` → „Aktualisieren" | ### Tier 2 — Server & Lifecycle | Element | Maßnahme | |---------|----------| | HTTP-Header | `server/static_cache.py` Middleware | | Focus | `registration.update()` + `version.json` Check | | `controllerchange` | Einmalig `location.reload()` | ### Tier 3 — Build | Element | Maßnahme | |---------|----------| | Quellen | `frontend/` | | Output | `public/assets/*.{hash}.js/css` | | Build | `python tools/build_frontend.py` (läuft im Dockerfile) | | Gehashte Assets | `Cache-Control: immutable` | ## Deploy-Checkliste - [ ] Version in `pyproject.toml` bumpen (optional) - [ ] `python tools/build_frontend.py` (Docker macht das automatisch) - [ ] `docker compose up -d --build` - [ ] Inkognito: `sw.js` neue CACHE-Konstante, `version.json` neuer `buildHash` - [ ] Alte PWA-Installation: Update-Banner nach App-Öffnung ## Anti-Patterns - Cache-first für unversioniertes `app.js` - `sw.js` im Precache - Stub-Endpoints für fehlende APIs - „Cache leeren" als einziger Fix in der Doku