Веб-работники против обещаний

Чтобы адаптировать веб-приложение, вы используете асинхронные неблокирующие запросы. Я могу представить два способа сделать это. Одним из них является использование отложенных/обещаний. Другой - веб-работники. С Web Workers мы в конечном итоге внедряем другой процесс, и на нас ложатся накладные расходы на то, чтобы перенаправлять данные туда-сюда. Я искал какие-то метрики производительности, чтобы понять, когда выбирать простые неблокирующие обратные вызовы вместо веб-работников.

Есть ли какой-то способ формулирования, который можно использовать без прототипирования обоих подходов? Я вижу много онлайн-уроков о Web Workers, но я не вижу много историй успеха/неудач. Все, что я знаю, я хочу адаптивное приложение. Я думаю использовать Web Worker в качестве интерфейса для структуры данных в памяти, которая может быть где-то от 0,5 до 15 МБ (по сути, БД), которую пользователь может запрашивать и обновлять.

Как я понимаю, обработка javascript позволяет взять одну длительную задачу и нарезать ее так, чтобы она периодически давала управление, позволяя другим задачам выделять часть времени обработки. Будет ли это признаком использования веб-работников?

ОТВЕТЫ

Ответ 1

"Отложенные/обещания и веб-работники удовлетворяют различные потребности:

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

  • Веб-работники выполняют фактическую работу асинхронно (используя потоки операционной системы, а не процессы - поэтому они относительно легки).

Другими словами, поскольку JavaScript является однопоточным, вы не можете использовать отложенные/обещания для асинхронного выполнения кода - после запуска кода, который выполняет обещание, никакой другой код не запустится (вы можете изменить порядок выполнения, например, с помощью setTimeout(), но это не делает ваше веб-приложение более отзывчивым). Тем не менее, вы можете каким-то образом создать иллюзию асинхронного запроса, например, перебирая массив значений, увеличивая индекс каждые несколько миллисекунд (например, используя setInterval), но это вряд ли практично.

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

  • используйте IndexedDB, который предоставляет асинхронный API,

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

  • используйте серверный скрипт-движок, такой как NodeJS, чтобы запустить ваш код, затем используйте клиентский ajax, чтобы запустить запрос (плюс обещание обработать результаты),

  • использовать базу данных, доступную по HTTP (например, Redis, CouchDB), и от клиента выполнить асинхронный GET (например, ajax) для запроса к БД (плюс обещание обработать результаты),

  • разработать гибридное веб-приложение, используя, например, Анализировать.

Какой подход является лучшим в вашем случае? Трудно сказать без точных требований, но вот размеры, на которые я бы посмотрел:

  • Сложность кода - если у вас уже есть код для вашей структуры данных, вероятно, веб-работники хорошо подойдут, в противном случае IndexedDB выглядит более разумным.
  • Производительность - если вам нужна постоянная производительность, реализация на стороне сервера или БД кажутся более подходящими
  • Архитектура/сложность - хотите ли вы, чтобы вся обработка выполнялась на стороне клиента, или вы можете позволить себе приложить усилия (затраты) для управления реализацией на стороне сервера?

Я нашел эту книгу полезной для чтения.