Повышение квалификации обслуживающего персонала

Вступление

Сервисные работники очень быстро превратились в нечто большее, чем просто модное периферийное устройство, это важное требование для создания безупречного и удобного взаимодействия как онлайн, так и офлайн. На сегодняшний день он очень сильно поддерживается большинством браузеров, даже IE 10 [1].

Дело для обслуживающего персонала:

Существует общее предположение о непрерывном взаимодействии в сети между несколькими конечными пользователями в разных странах, связанными разными сетевыми ограничениями. Мы легко забываем, что цель Интернета среди многих состоит в том, чтобы создавать точки ресурсов по различным предметам, делая их легкодоступными, сохраняя при этом целостность данных по форме, качеству и опыту. Без этой уверенности можно было бы утверждать, что это ничем не лучше, чем наша давняя любовь к почте и газетам. Что вполне может гарантировать гораздо более непрерывный опыт без очень популярного и абсолютно необходимого тысячелетнего опыта «реального времени». Если бы существовал способ имитировать эту возможность в сети, своего рода иллюзию, удовлетворяющую наши геоэкономические различия.

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

Стандартный надуманный пример ниже, чтобы дополнительно объяснить операцию блокировки:

HTML

<input type="text" placeholder="name" />

input = document.querySelector("input");
input.addEventListener("input", function(event){
  // do some stuff here
  alert("block")
})

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

Сервис-воркеры - это разновидность веб-воркеров в стеке веб-браузера [2]. Идея в основном заключается в запуске отдельного потока от основного потока пользовательского интерфейса, в котором в настоящее время выполняется веб-приложение. Как вы можете догадаться, это может быть легко полезно в областях, где сложная бизнес-логика может быть выгружена для обработки, в то время как основное приложение остается без ограничений.

Одна из тревожных ошибок системы безопасности, которая может иметь в виду, - это возможность атаки DOS, порождающей несколько потоков из браузера пользователя. Однако никакая реализация веб-воркеров в браузере не обещает новый поток, порожденный для каждой инициализации подпроцесса веб-воркеров [3]. Но с большой уверенностью можно сказать, что веб-воркеры будут назначены одному потоку, абсолютно отличному от основного потока пользовательского интерфейса, который запускает текущее веб-приложение [3].

Веб-воркеры делятся на два основных типа:

Общий рабочий
Выделенный работник

ОБЩИЙ РАБОТНИК

Общий воркер может использоваться на нескольких страницах в приложении. Или одно приложение. Связь с этим воркером может происходить между страницами.

ВЫДЕЛЕННЫЙ РАБОТНИК

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

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

СВЯЗЬ МЕЖДУ СТРАНИЦАМИ И ВЕБ-РАБОТНИКАМИ

Передача данных между веб-воркерами и страницами происходит с помощью структурированного алгоритма клонирования [4]. Это в основном структурирование данных с одной стороны и их анализ с другой стороны. Это очень похоже на такие операции, как запись в indexDB, localStorage, sessionStorage и т. Д. Однако важно отметить, что, как и другие, функции и ошибки нельзя передавать туда и обратно. Такой подход имеет очевидные недостатки памяти. альтернативой может быть использование разделяемого буфера массива ES7 [5] для предотвращения копирования и вставки данных между страницами и веб-рабочими.

ГЛУБОКОЕ ПОГРУЖЕНИЕ ВЕБ-РАБОТНИКА

Чтобы быстро погрузиться в детали воркеров, рассмотрим приведенный ниже пример кода:

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

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

Функция genFib ссылается на указанную выше функцию startFib, которая ожидает, что параметр «n» вычислит число Фибоначчи. setTimeout, помещенный в функцию genFib, гарантирует, что следующее число Фибоначчи будет сгенерировано после вызова self.postMessage и очистки цикла событий.

HTML:

<h1>Contrived Example</h1>
<button class="start-fib">Start</button>
<div class="fib-body">
<ul></ul>
</div>

Как видно из вышесказанного, функция Фибоначчи вызывается и обрабатывается в отдельном потоке благодаря веб-воркеру. После того, как процесс завершен, веб-воркер возвращает результат через событие, генерируемое после того, как сгенерирован каждый n-й член в последовательности. Этот процесс не искажает основной поток пользовательского интерфейса, когда я пытаюсь прокрутить и выделить экран. Процесс Фибоначчи происходит отдельно, не обращая внимания на то, что в данный момент делает пользователь.

СЕРВИСНЫЕ РАБОТНИКИ

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

Сервис-воркеры - это прокси-серверы, которые находятся в нашем браузере. Он взаимодействует с каждым запросом, который отправляется браузером вперед и назад. даже если вкладка браузера не открыта, он все равно может взаимодействовать с сервером от имени браузера.

Использование Service Workers

Очень хороший совет при использовании сервис-воркеров - понимание жизненного цикла сервис-воркера. сервисный работник находится в одном из трех (3) состояний одновременно.

установка
ожидающий
активный

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

Сервисный работник глубокое погружение.

СОЗДАНИЕ НОВОГО РАБОТНИКА СЕРВИСА

const serviceWorkerRegistration = navigator.serviceWorker.register(
   "/sw.js",
   {updateViaCache: "none"}
);

const serviceWorker = 
serviceWorkerRegistration.installing ||
serviceWorkerRegistration.waiting||
serviceWorkerRegistration.active;
navigator.serviceWorker.addEventListener("controllerchange", () => { serviceWorker = navigator.serviceWorker.controller;  
sendServiceWorkerMsg({ping:"Hi, there I am a page"})
const sendServiceWorkerMsg = (msg, target) => {
   if (target) { target.postMessage(msg);
   } else if (serviceWorker) { serviceWorker.postMessage(msg);
   } else { navigator.serviceWorker.postMessage(msg);}
}

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

У Service worker есть обязательные жизненные циклы, которые должны произойти, чтобы Service worker взял под свой контроль страницу или приложение. Одним из основных недостатков этого жизненного цикла является тот факт, что пользователь может запускать устаревшую версию вашего приложения, потому что новый Service Worker не активирован. следовательно, пользователю придется перенаправить на другую страницу, а затем обратно на страницу, на которой он должен был увидеть новые изменения.

СВЯЗЬ МЕЖДУ СТРАНИЦАМИ И ВЕБ-РАБОТНИКАМИ

navigator.serviceWorker.addEventListener("message",(event) => {  
    console.log(data.msgFromServiceWorker); // {pong: "hi there fr"}
    console.log(data.ports)
});

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

const sendMessage  = (msg) => {
   var allClients = await clients.matchAll({ includeUncontrolled:    true });
   console.log("all the connected clients", allClients);
   return Promise.all( allClients.map(client => {
   const newChannel = new MessageChannel();
   newChannel.port1.onmessage = serviceWorkerMessageHandler; 
   return client.postMessage(msg, [newChannel.port2]);}));
}

Переменная allClients нацелена на все вкладки или окна, которые работник службы в настоящее время контролирует / активен. Это не похоже на веб-воркера, у которого была только одна выделенная вкладка для одного веб-воркера.

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

CACHE API

Кеш в браузере обрабатывает сетевые запросы, то есть, когда ресурсы / активы требуются для сетевых запросов в наших приложениях, браузер проверяет кеш, чтобы найти запрошенный ресурс. Если он существует, он загружает его из кеша. В противном случае он начнет свой обычный запрос сети через огромную массу Интернета, чтобы найти его. Думайте о кеш-хранилище как о хранилище ключ-значение, как об объекте в javascript. Для кеша ключи - это пути URL, а значения - объекты ответа. Говоря об объектах ответа, очень важно отметить, что эти объекты ответа можно использовать только один раз. Для дальнейшего использования потребуется клон. Обычно это достигается путем вызова метода clone для объекта ответа из ответа ajax.

Пример ниже:

const cacheAbleUrls = [
"/styles.css",
"/index.html",
"about.html",
"/index.js",
"/dashboard.js"
];
const saveToCache = async (refresh = false) => {
  let cache = await caches.open("some-random-cache-name");
  let res;
  if (!refresh) {
      return Promise.all(
       cacheAbleUrls.match(async url => {
       res = await cache.match(url);
       return res;
       })
     );
  }
   res = await fetch(url, {
       method: "GET",
       credentials: "omit",
        cache: "no-cache",
    });
   if (res.ok) {
   await cache.put(url, res);
    }
  };

Как видно выше, функция saveToCache принимает логический аргумент, который позволяет переключать действие кэширования. Это подойдет для случаев, когда вам нужна новая загрузка кеша, то есть новое обновление стилей или скриптов.

ССЫЛКИ

[1] https://caniuse.com/#search=web%20workers

[2] https://developer.mozilla.org/en-US/docs/Web/API/Worker

[3] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

[4] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm

[5] https://medium.com/@SitePen/the-return-of-sharedarraybuffers-and-atomics-a254032e00a6

Повышение квалификации обслуживающего персонала