Кеширование
SWR: тест на свободное воспроизведение
Воспроизведение по памяти лучше перечитывания. На каждую подсказку проговори или запиши полный ответ из памяти, прежде чем открыть модельный — усилие воспроизведения и закрепляет модель «свежесть против задержки».
Восстанови спину юнита — два окна, компромисс задержки, stale-if-error, single-flight, клиентскую модель и границу auth — не подглядывая в урок.
- 01Почему один лишь max-age порождает пилу p99, и как stale-while-revalidate её сглаживает?
- 02Прочитай заголовок max-age=60, stale-while-revalidate=300, stale-if-error=86400 как вложенные окна. Что происходит в каждом?
- 03Что такое стадо фоновых обновлений и как его предотвратить?
- 04Почему устаревание всегда должно быть ограничено и что идёт не так без ограничения?
- 05Как клиентские библиотеки вроде SWR и React Query реализуют тот же паттерн, и какие два поведения добавляют поверх сырого заголовка?
- 06Когда stale-while-revalidate — неправильный инструмент, и каково правило сеньора?
Если ты смог восстановить каждый ответ по памяти, ты держишь спину юнита: один max-age сэмплирует промах кэша в p99, stale-while-revalidate выносит обновление из пути запроса и сглаживает пилу, слоёный заголовок — это три вложенных окна (свежее, SWR, stale-if-error), single-flight плюс джиттер укрощают стадо фоновых обновлений, устаревание должно быть жёстко ограничено, чтобы упавший origin не отдавал контент неизвестного возраста вечно, клиентские библиотеки воспроизводят модель через dedupingInterval и ревалидацию на focus/reconnect, а к auth SWR не применяется никогда.