Как я могу адаптировать пересмотр статического ресурса gulp для работы с ServiceWorkers?
Контекст: у меня есть производственное приложение ( здесь, если вы хотите посмотреть), которое в настоящее время использует пересмотр статического ресурса с использованием 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?
Одна вещь, которая будет полезна, это просто ссылка на примеры того, как другие производственные приложения справляются с этим.
2 ответа
Работник сервиса лучше всего работает на основе хорошей стратегии регулярного кэширования. Вы должны продолжить пересматривать ваши статические имена файлов, а затем кэшировать их в сервисном работнике. Избегайте библиотек, которые изменяют URL через строку запроса, эта функция вам не нужна, так как вы уже пересматриваете URL.
Если ваши активы обслуживаются из другого источника (я думаю, это то, что вы имеете в виду, когда говорите "быстро"), тогда разрешите запрашивать их через CORS (через Access-Control-Allow-Origin: *), это означает, что они не будут непрозрачными.
Вы должны сохранить проверенные файлы активов. Для полного примера использования gulp и предварительного кэширования посмотрите здесь.
Вы в основном хотите использовать сначала кеш, а затем сетевой шаблон. Вы можете сопоставить запросы с /goals.*.js/ =>, а затем, в зависимости от вашего приложения, вы можете решить использовать кэшированные goal.js, даже если [hash] не совпадает, и затем загрузить новые цели. [hash].js в фоновом режиме.
Или, если хеш не совпадает, вы можете сначала обратиться к сети, откатившись к нечеткому совпадению кеша goal.js.
Что касается Nginx. Часто предлагается использовать обратный прокси-сервер для обслуживания статических активов. Node.js не подходит для этой задачи. Вот хороший рабочий пример. Если вы выполните эту настройку, ваш поток статических ресурсов будет выглядеть следующим образом:
CDN => <= Nginx => Источник Node.js.
Если вы используете AWS. Тогда типичная установка с Cloudfront CDN будет включать в себя установку вашего обратного прокси-сервера Nginx EC2 в качестве источника. Затем вы должны настроить поведение для маршрута "/" и своего маршрута "/assets".
Поведение "/", скорее всего, будет иметь короткий TTL, а поведение "/assets/" (маршрут в Cloudfront) будет иметь вашу долгосрочную (max-age=3153600) стратегию кэширования.
В этом сценарии почти все статические ресурсы будут обслуживаться из CDN (Cloudfront). Он вернется к исходному состоянию только тогда, когда вы развернете новый код с новым набором исправленных файлов ресурсов.
Затем вы используете сервисного работника, чтобы сделать все повторные посещения чрезвычайно быстрыми, потенциально даже используя устаревший ресурс (совпадающее имя, другой хэш) при первом повторном посещении, сначала перейдя в кэш, а затем в сеть. Таким образом, все повторные пользователи с работником службы будут иметь максимально быструю начальную загрузку страницы.
Те, у кого его нет, по-прежнему получат все преимущества долгосрочного кешированного ресурса браузера с файловой поддержкой CDN.