swPrecache и CDN в качестве прокси?

Я использую swPrecache для загрузки моих статических ресурсов моего PWA, чтобы поддерживать автономный режим. Он отлично работает. Моя установка выглядит примерно так:

https://www.myexampledomain.com/myapp/ загружает статический index.html, который, в свою очередь, load использует swPrecache для загрузки статических ресурсов, таких как JS, изображения, CSS и т. д. Имейте в виду, что все они загружаются из одного и того же домена, например, www.myexampledomain.com/myapp/js/file1.js.

Но мой список swprecache содержит приличное количество файлов, и его загрузка занимает некоторое время при медленном интернет-соединении. К вашему сведению, я уже откладываю регистрацию сервисного работника на что-то вроде события «загрузка».

Итак, вот что я сейчас пытаюсь сделать. Мне нужен кто-то, чтобы проверить, возможно ли это:

  1. https://www.myexampledomain.com/myapp/ загружает статические HTML-файлы, как и раньше.
  2. Попросите swPrecache перехватывать статические запросы, которые идут к домену приложения (например, https://www.myexampledomain.com/myapp/js/file1.js) и вместо этого получать их в конечную точку CDN? (например, https://some.cloudfront.com/myapp/js/file1.js< /а>).
  3. После загрузки swPrecache продолжает работать как обычно.

Так что, по сути, я надеюсь, что swPrecache проксирует запросы статических активов в CDN, чтобы ускорить загрузку во время начальной загрузки.

Любые комментарии / указатели на это помогут.


javascript cdn service-worker sw-precache
person Ravi Gidwani    schedule 03.05.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете использовать параметр stripPrefixMulti в sw-precache, чтобы изменить URL-адреса, записанные на ваш сервисный рабочий файл. Однако это довольно грубая сила, поэтому полезно, если есть общий префикс, который используется всеми активами, которые будут обслуживаться из CDN.

Например, если все, что будет обслуживаться вне CDN, хранится в локальном каталоге assets/, а их пути в CDN будут начинаться с https://my-cdn.com/assets/, вы можете использовать

{
  stripPrefixMulti: {'assets/': 'https://my-cdn.com/assets/'},
  // ... other sw-precache options...
}

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

person Jeff Posnick    schedule 04.05.2017
comment
Я пробовал это, но это не работает для меня. Как я понимаю, stripPrefix/stripPrefixMulti: во время сборки при создании service-worker.js он удаляет указанный префикс и заменяет его строкой замены. Я ищу способ указать домен, который можно использовать для запроса/получения URL-адресов. Глядя на service-worker.js, что-то эквивалентно: var request = new Request(cacheKey.replace(self.location.hostname,"my-cdn.com"), {credentials: 'same-origin'});. Кажется, это работает, если я вручную изменяю сервис-воркер. Я делаю что-то неправильно? - person Ravi Gidwani; 05.05.2017
comment
Что произошло, когда вы попробовали stripPrefixMulti? Это самое близкое к вашему варианту использования с sw-precache. Вариант использования CDN для некоторых ресурсов — это потенциальное минное поле, поскольку ваш файл sw.js одного и того же происхождения и ваши ресурсы удаленного происхождения обязательно развертываются в два разных этапа, и любое незавершенное или отложенное развертывание может привести к тому, что устаревший контент будет кэшироваться на неопределенный срок. . Так что это не то, что я действительно хочу сделать легким. - person Jeff Posnick; 05.05.2017

arrow_upward
0
arrow_downward

да, вы можете использовать

{
   stripPrefixMulti: {'assets/': 'https://my-cdn.com/assets/'},
   // ... other sw-precache options...
 }

но я уверен, что вы столкнетесь с новой проблемой CORS. я тоже над этим работаю

person DappWind    schedule 03.07.2017