Когда я должен разделить какую-то задачу на асинхронные более мелкие задачи?

Question

Я пишу персональный проект в Node и пытаюсь выяснить, когда задача должна быть асинхронно разделена. Допустим, у меня есть эта «4-шаговая задача», они не очень дорогие (самый дорогой - это тот, кто перебирает массив объектов и пытается сопоставить URL с RegExp, а массив, вероятно, не будет иметь более 20 или 30 объектов).

part1().then(y => {
  doTheSecondPart
}).then(z => {
  doTheThirdPart
}).then(c => {
  doTheFourthPart
});

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

Существуют ли какие-либо критерии относительно того, когда этот подход следует предпочитать классическому c синхронному?

Извините, мой плохой английский sh, но не мой родной язык.

Answer 1

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

Если вы заставляете даже синхронный код в обещание, то обработчик .then() даст возможность некоторому другому коду работать между обработчиками .then(), но только определенные типы событий могут запускать там, потому что обработка разрешенного обещания является одной из самых приоритетных задач в системе очереди событий. Например, он не разрешит запуск другого входящего http-запроса, поступающего на ваш сервер.

Если вы действительно хотите разрешить выполнение других запросов и т. Д., Было бы лучше просто поместить код (без обещаний) в WorkerThread и позволить ему запускаться там, а затем сообщать результат с помощью обмена сообщениями. Если вы хотите сохранить его в главном потоке, но разрешить запуск любого другого кода, вам, вероятно, придется использовать небольшую задержку setTimeout(), чтобы действительно позволить всем возможным другим типам задач выполняться между ними.

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

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

Что касается кода, который перебирает массив / список элементов, выполняющих сопоставление с некоторая строка, это именно то, что инфраструктура веб-сервера Express делает для каждого входящего URL, чтобы найти подходящие маршруты. Это не медленная вещь в Javascript.

Answer 2

Асинхронное программирование лучше подходит для кода, который должен реагировать на события, например, для любого графического интерфейса пользователя. Примером ситуации, когда программисты используют asyn c, но не должны, является любой код, который может полностью сосредоточиться на обработке данных и может принять блок «остановка мира» в ожидании загрузки данных.

Я широко использую его с сервером остальных API, поскольку мы не знаем, сколько времени может занять запрос, чтобы сервер ответил. Поэтому для того, чтобы мы не «блокировали приложение» во время ожидания ответа сервера, наиболее полезными являются асинхронные c запросы

part1().then(y => {
doTheSecondPart
 }).then(z => {
 doTheThirdPart
 }).then(c => {
 doTheFourthPart
 });

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

В этом случае следует использовать Asyn c Await, где вы ожидаете ответа пользовательского события или сервера, но не хотите, чтобы ваше приложение зависало при ожидании данных сервера ...

async function wait() {
  await new Promise(resolve => setTimeout(resolve,2000));
   console.log("awaiting for server once !!")
  return 10;
}

async function wait2() {
  await new Promise(resolve => setTimeout(resolve,3000));
   console.log("awaiting for server twice !!")
  return 10;
}

async function f() {

  let promise = new Promise((resolve, reject) => {
  
    setTimeout(() => resolve("done!"), 1000)
  });

  




 let result = await promise;//.then(async function(){
     console.log(result)
  let promise6 = await wait();
  let promise7 = await wait2();
   
//}); // wait until the promise resolves (*)

  //console.log(result); // "done!"
}

f();

Этот пример должен помочь вам получить базовое c понимание того, как работает асинхронное / ожидание, и вот несколько ресурсов для его изучения Обещания и Асин c Mozilla Refferences