Загальновідомо, що JS може працювати лише в одному потоці, тобто усі дії та обчислення ставляться в чергу. І коли вони виконуються, будь-які інші дії "блокуються", тобто мусять дочекатися, доки завершиться поточний обрахунок.
Це призводить до різних незручностей, зокрема "зависання" інтерфейсу при ресурсоємних обчисленнях. Звичайно, мій уважний читач одразу зазначить, що це проблема архітектури. Але якщо у нас відсутня можливість запускати такі обрахунки в паралелі, то у нас просто немає виходу.
Чи є? Уже тривалий час ми маємо доступ до так званих воркерів — можливості запускати окремі ізольовані контексти виконання, з
Перший драфт, до речі, зʼявився ще 2009 року. І того ж року його підтримку додали в Firefox 3.5 та Chrome 4. З тих пір можливості цього стандарту тільки зростали, як і поширення його запровадження в бравзерах. А з 2019 року стабільна підтримка воркерів зʼявилася і в NodeJS.
Важливо памʼятати — воркер не має доступу до "зовнішнього світу", тобто глобального оточення, з якого його запустили. Це значить — ніякого прямого доступу до DOM, window чи document. Вважайте їх за таку собі "пісочницю".
Але ж який в них тоді сенс, спитаєте ви? Ну, не такі вони вже й ізольовані. Існує спеціальний інтерфейс спілкування з воркерами, який підтримує метод
postMessage для надсилання повідомлень і onmessage для їх обробки. Це викликає в голові мою улюблену аналогію з печерою, коли воркер весь час сидить в ній і виконує свою задачу, а ми в той час займаємось своїми справами. Коли нам треба щось — ми кидаємо в печеру записку із завданням, а через якийсь час воркер викидає з неї результат.// main.js
const worker = new Worker('worker.js');
worker.postMessage('Зроби шось!');
worker.onmessage = e => {
console.log(e.data);
}
// worker.js
onmessage = e => {
postMessage(
'Зробив шось, забирай'
);
});
Наразі існує декілька видів воркерів, кожен з яких має своє призначення.
Почнемо з Dedicated Worker. Він належить тільки тій сторінці, яка його створила і закінчує своє існування разом з нею. Це якраз класичний приклад додаткового процесу, який обмежений однією вкладкою. Але якщо нам треба воркер, який вміє спілкуватися з кількома вкладками?
Для цього існує SharedWorker. Він поводиться рівно так само, як і звичайний, але при цьому до нього можуть підключатися різні вкладки з нашим застосунком. І "живе" він теж до останнього підключення.
А коли нам потрібно, аби воркер жив та існував незалежно від того, чи відкрита хоч одна вкладка, ба більше, незалежно від того, чи запущено бравзер взагалі (ну, тут перебільшення, має бути запущено фоновий процес бравзера, але це вже глибокі деталі), ми можемо використати ServiceWorker.
Це свого роду наш кишеньковий сервер, який вміє працювати з фоновими завданнями, має доступ до великої кількості API, таких як Cache, Background Sync, Push та багатьох інших. Його основне завдання — виступати посередником між нашим застосунком, локальним кешем та мережею. Саме на ньому базується можливість створення offline-first застосунків.
Якщо підсумувати, то кожен воркер має свою сферу відповідальности: уявіть, що Worker — це комірник одного магазину, SharedWorker обслуговує кілька відділень, а ServiceWorker вже виступає як регіональний менеджер, і займається вже не нагальними справами, а, радше, забезпечує функціонування торговельної мережі навіть у позаробочі години.
Воркери вирішують проблему однопоточности JavaScript, хай і в дещо неочевидний спосіб. Вони дозволяють перебрати з основного потоку усі важкі та ресурсозатратні обрахунки, залишаючи йому лише займатися оновленням UI.
Що почитати:
📖 MDN: Web Workers API
📖 MDN: SharedWorker
📖 MDN: Service Worker
Що почитати душнілам:
📖 WHATWG: Web Workers Standard
📖 W3C / WHATWG: Service Workers
Підписуйтесь: @babichdev