Механизм доставки для JavaScript-пакета, потребляемого несколькими клиентами - PullRequest
0 голосов
/ 15 ноября 2018

Сценарий :

Общий компонент, реализованный в виде микро-интерфейса и размещенный на S3 ...

  • Пакет JS, содержащий все приложение (в веб-упаковке), размещенное на S3
  • Пакет JS содержит хэш с последним коммитом, например, компонент. {} хэш .js

Вопрос

Когда мы отправляем новый пакет, какова лучшая стратегия для обеспечения того, чтобы новый пакет потреблялся всеми клиентами после выпуска, принимая во внимание кэширование браузера / CDN? Важное примечание: мы хотим, чтобы клиент получал обновления немедленно (внутри).

Примеры

  1. При выпуске создайте файл component.html, который извлекает пакет (тег скрипта) на основе последнего хэша. Отправьте новый файл component.html на S3. Клиенты используют <link rel-'import' href='somedomain.com/component.html'>, всегда предоставляя им последнюю поставленную версию.

Проблема: пакет может по-прежнему использовать кэширование на CD / в браузере, но HTML-файл не может быть кэширован, так как нам нужно, чтобы он был горячим для любого выпуска. Также кажется странным, что нам нужно сделать две загрузки, чтобы просто попасть в один пакет.

  1. Поставляется в качестве модуля NPM, который может использоваться клиентом во время сборки.

Проблема: если у нас есть 10 клиентов, все 10 необходимо собрать и отправить с новым компонентом. Предполагая, что package.lock не вызовет проблем с подстановочными знаками (недостаточно хорошо это знаю).

Примечание: внутренний компонент; могут подвергаться частым изменениям, например AB тестирование и т. Д.

1 Ответ

0 голосов
/ 22 ноября 2018

Как правило, важно, чтобы страница / приложение, использующее ваш компонент, тестировалась и обновлялась любой новой версией вашего компонента.Поэтому ваша идея использования NPM хорошая.Как правило, желательно иметь это время задержки, чтобы разработчики страниц / приложений могли проверять функциональность, а также обрабатывать любые изменения API, которые могли произойти (преднамеренные или нет).

Для NPM, Семантическое управление версиями(SemVer) является стандартом де-факто.Идея состоит в том, что вы нумеруете свои версии таким образом, чтобы исправления (без изменений API) можно было немедленно обновлять в приложениях. Некоторые разработчики согласны с установкой последней версии патча вашего модуля. Многие предпочитают блокироваться для определенной версии и выпускают только после тестирования, как и любое другое обновление.

Помимо NPM, в прошлом я использовал хешированные или версионные URL длябиблиотека.Я также сохранил URL latest, который перенаправляет на последнюю версию.Для тех, кто интегрирует мою библиотеку, которым все равно, какая у них версия, они всегда получат последнюю версию таким образом.Кроме того, браузеры могут кешировать цель перенаправления и делиться этим кешем с другими страницами, которые могут указывать точную версию.

Важное примечание: мы бы хотели, чтобы клиент получал обновления немедленно (внутренние).

Это не совсем возможно во всех случаях.В большинстве случаев использование правильных заголовков ответов для кэширования решит эту проблему.Хотя есть крайние случаи.Например, что вы будете делать, если пользователь загружает страницу, а затем отключается до того, как загружается ваш JavaScript?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...