Как я могу адаптировать пересмотр статического ресурса gulp для работы с ServiceWorkers?

Question

Контекст: у меня есть производственное приложение ( здесь , если хотите посмотреть), которое в настоящее время использует пересмотр статического ресурса с использованием пакета gulp-rev-all , который похож на gulp-rev, за исключениемчто он также обрабатывает зависимости при генерации хэшей контента.Он генерирует новый набор файлов, которые имеют статические имена (например, goals.js становится goals.6a5aa614.js) и которые ссылаются друг на друга, используя эти статические имена.Затем я передаю эти файлы вместе с Fastly CDN на производстве, поэтому мой сервер NodeJS не используется активно для статических ресурсов.Это прекрасно работает.

Сейчас я работаю над тем, чтобы сайт работал в автономном режиме с сервисными работниками.Поскольку в прошлом году я проделал большую работу по логике синхронизации, динамическую часть сайта было довольно легко перестроить.Но я немного растерялся из-за того, что делать с моими статическими активами.

Я подумал, что буду использовать рабочий ящик, и это, похоже, работает нормально.Но workbox precache использует запросы для очистки кэша, а не для изменения имен файлов, и кажется глупым делать и то, и другое.Но если я перестану использовать версионные имена, то как мне разрушить кеш в браузерах, которые не поддерживают сервисный работник?

(у меня есть еще один связанный вопрос, который имеет смысл сохранитьиспользование Fastly, учитывая, что ответы Fastly будут непрозрачными для SW и, следовательно, не обязательно являются хорошим вариантом для предварительного кэширования? Хотя без Fastly приложение станет намного медленнее для тех, кто не использует сервисных работников, что звучит противоположно подходу PWA.Должен ли я добавить кеш nginx или что-то в этом роде? (Я понятия не имею, что это такое, но я слышал, что это упоминалось несколько раз))

Мне кажется, что должно быть элегантное решениедля этого, но мое понимание gulp достаточно ограничено, поэтому мне трудно понять, что возможно, а мое понимание ServiceWorkers и кэширования достаточно ограничено, и мне трудно точно знать, чего я хочу.

Поэтому у меня возникли проблемы с получением ответа на этот вопрос:

Как я могу адаптировать пересмотр статического ресурса gulp для работы с ServiceWorkers?

Одна вещь, которая будет полезна, это просто ссылка на примеры того, как другие производственные приложения обрабатывают это.

Answer 1

Вы должны сохранить проверенные файлы активов.Для полного примера использования gulp и предварительного кэширования посмотрите здесь .

В основном вы хотите использовать сначала кеш, а затем сетевой шаблон.Вы можете сопоставить запросы с /goals.*.js/ =>, а затем, в зависимости от вашего приложения, вы можете решить использовать кэшированные goal.js, даже если [hash] не совпадает, и затем загрузить новые цели. [hash] .js в фоновом режиме.

Или, если хеш не совпадает, вы можете сначала обратиться к сети, чтобы вернуться к нечетко сопоставляемому кешу goal.js.

Что касается Nginx.Часто предлагается использовать обратный прокси-сервер для обслуживания статических активов.Node.js не подходит для этой задачи.Вот хороший рабочий пример .Если вы выполните эту настройку, поток статических ресурсов будет выглядеть следующим образом:

CDN => <= Nginx => Node.js Origin.

Если вы используете AWS.Тогда типичная установка с Cloudfront CDN будет включать в себя установку вашего обратного прокси-сервера Nginx EC2 в качестве источника.Затем вы должны настроить поведение для маршрута "/" и маршрута "/ assets".

В поведении "/" скорее всего будет короткий TTL, а в поведении "/ assets /" (маршрут в Cloudfront) будет иметь вашу долгосрочную (max-age = 3153600) стратегию кэширования.

В этом сценарии почти все статические ресурсы будут обслуживаться из CDN (Cloudfront).Он вернется к исходному состоянию, только когда вы развернете новый код с новым набором файлов с измененными ресурсами.

Затем вы используете сервисного работника, чтобы сделать все повторные посещения чрезвычайно быстрыми, потенциально даже используя устаревшиересурс (соответствующее имя, другой хеш) при первом повторном посещении, сначала перейдя в кеш, а затем в сеть.Таким образом, все повторяющиеся пользователи с работником службы будут иметь как можно более быструю начальную загрузку страницы.

Те, у кого его нет, по-прежнему получат все преимущества обновленных файлов, долгосрочных кэшированных ресурсов браузера с обслуживанием края CDN.*

Answer 2

Сервисный работник лучше всего работает на основе хорошей стратегии регулярного кэширования.Вы должны продолжить пересматривать ваши статические имена файлов, а затем кэшировать их в сервисном работнике.Избегайте библиотек, которые изменяют URL через строку запроса, вам не нужна эта функция, так как вы уже пересматриваете URL.

Если ваши активы обслуживаются из другого источника (я думаю, это то, что вы имеете в виду, когдаВы говорите о Быстро), затем разрешите запрашивать их через CORS (через Access-Control-Allow-Origin: *), это означает, что они не будут непрозрачными.