Thema: caching
-
Einen Service Worker sicher ausrollen: Scope, versionierte Caches, der wartende Worker und ein Notausschalter
Ein Service Worker, der HTML cacht, kann Nutzerinnen und Nutzer nach einem Deployment an alten Code binden. Ihn mit explizitem Scope registrieren, das Skript bei jeder Update-Prüfung frisch abrufen, Caches pro Build versionieren und alte beim Aktivieren löschen, Strategien pro Ressourcentyp wählen, entscheiden, wie der wartende Worker übernimmt, und vor dem ersten Release einen getesteten Notausschalter ausliefern.
-
Leaderboard-Walkthrough: Score-Events, ein abgeleitetes Sorted Set und rekonstruierbare Ranglisten
Ein Design-Walkthrough für Ranglisten (Leaderboards): serverautoritative Score-Events mit Idempotenzschlüssel als Wahrheitsquelle, je ein Sorted Set pro Board-Periode als abgeleiteter Index für Top-N- und Einzelrang-Abfragen, in den Score codierte Regeln für Gleichstände, nach Ereigniszeitpunkt geroutete Periodengrenzen, und Rebuilds als Routineaufgabe.
-
Cache-Control-Direktiven: max-age, no-store, private und stale-while-revalidate
Cache-Control teilt Browser- und Shared Caches mit, wie lange eine Antwort wiederverwendet werden darf und wo sie gespeichert werden darf: max-age und s-maxage legen die Frische fest, no-cache erzwingt eine Revalidierung vor der Wiederverwendung, no-store verbietet die Speicherung, private hält eine Antwort aus Shared Caches heraus, und stale-while-revalidate sowie stale-if-error (RFC 5861) lassen einen Cache veraltete Inhalte ausliefern, während er sie aktualisiert oder während Fehlern. Eine Antwort ohne Direktiven kann dennoch heuristisch zwischengespeichert werden.
-
Bedingte GETs für sich ändernde Feeds verwenden
Eine Feed-Darstellung zusammen mit ihrem Validator zwischenspeichern und sie nach einem 304 korrekt wiederverwenden, ohne Nutzende, Sprachen oder Query-Varianten zu vermischen.
Maschinenlesbar: JSON