tigir.com

Паттерны асинхронности в Js: promises и async/await, очереди задач и отмена запросов

Для устойчивой асинхронности в JavaScript используйте Promises для композиции и единообразной обработки ошибок, async/await для читаемого потока и локальных try/catch, очереди задач для ограничения параллелизма и защиты API, а AbortController и таймауты — для отмены и предотвращения зависаний. Ниже — практические паттерны, примеры и безопасные проверки.

Краткий обзор подходов к асинхронности в JS

Паттерны работы с асинхронностью в JS: Promises, async/await, очереди задач и отмена запросов - иллюстрация
  • Promises удобны для параллельных веток и комбинирования через all/allSettled/race/any, но требуют дисциплины в обработке ошибок.
  • async/await делает код линейным и упрощает try/catch, но легко «случайно» сериализовать независимые операции.
  • Очереди задач (concurrency limit, throttling, batching) защищают сеть/бекенд и UI от шторма запросов.
  • Отмена через AbortController и таймауты нужна по умолчанию для UX и чтобы не копить «висящие» операции.
  • Устойчивость = частичные ошибки + ретраи + откат + идемпотентность, а не «один большой try/catch».

Как работают промисы: механика, ошибки и паттерны обработки

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

Когда не стоит: если вам нужна отмена «из коробки» без явного контракта (Promises сами по себе не отменяются) или если команда часто допускает незакрытые ветки ошибок — тогда сначала введите стандарты и обертки.

Базовый шаблон: возвращайте промис и всегда нормализуйте ошибки

function loadJson(url, { signal } = {}) {
  return fetch(url, { signal })
    .then((r) => {
      if (!r.ok) throw new Error(`HTTP ${r.status}`);
      return r.json();
    })
    .catch((err) => {
      // Нормализация/обогащение ошибки - полезно для логирования и UI
      err.context = { url };
      throw err;
    });
}

Паттерны обработки: all/allSettled

const tasks = ["/a", "/b", "/c"].map((p) => loadJson(p));
const results = await Promise.allSettled(tasks);

const ok = results
  .filter((x) => x.status === "fulfilled")
  .map((x) => x.value);

Типовые векторы отказа (и что делать)

  • Uncaught (in promise) из-за забытых catch или неawait-нутых цепочек: включайте правило линтера и тест на необработанные отклонения.
  • «Проглатывание» ошибки при catch без повторного throw: возвращайте fallback осознанно и документируйте контракт.
  • Подмена контекста (непонятно, какой URL/параметры упали): добавляйте context в ошибку или используйте typed errors.
  • Ложное ощущение отмены: промис продолжит выполняться, если вы не остановили источник (например, fetch через AbortController).

Сравнение Promises, async/await и очередей (риски и trade-offs)

Подход Сильные стороны Риски/ограничения Когда применять
Promises (цепочки) Композиция, параллелизм, стандартные комбинаторы (all*) Легко потерять обработку ошибок; отмена не встроена Пайплайны данных, комбинирование задач, библиотеки
async/await Читаемость, локальные try/catch/finally, проще профилировать Случайная сериализация; ошибки скрываются при «пустом» catch Сценарии UI/сервиса, где важен понятный поток
Очереди задач (лимит параллелизма) Защита API/браузера, контроль нагрузки, предсказуемость Нужны правила приоритета/повторов; сложнее отлаживать Массовые загрузки, фоновые синки, обработка списков

Если вы выбираете учебник javascript асинхронность или точечно докупаете практику (например, javascript promises купить курс), ищите примеры с allSettled, лимитами параллелизма и отменой — именно они чаще всего ломаются в продакшне.

async/await: явные сценарии, контроль ошибок и оптимизация потока

Что понадобится: современный рантайм (браузер/Node.js) с поддержкой async/await и AbortController, доступ к логированию (Sentry/аналог или хотя бы централизованный logger), а также линтер/formatter (ESLint/Prettier) с правилами на необработанные промисы.

Шаблон: один try/catch на сценарий + finally для очистки

async function loadProfile(signal) {
  try {
    const [me, settings] = await Promise.all([
      loadJson("/api/me", { signal }),
      loadJson("/api/settings", { signal })
    ]);
    return { me, settings };
  } catch (err) {
    // Разделяйте отмену и реальные ошибки
    if (err.name === "AbortError") return null;
    throw err;
  } finally {
    // Очистка: снять спиннер, закрыть ресурсы, сбросить флаги
  }
}

Оптимизация потока: не сериализуйте независимые операции

  • Плохо: await a(); await b(); если a и b не зависят друг от друга.
  • Хорошо: запустить обе, затем дождаться вместе: const pa=a(); const pb=b(); await Promise.all([pa,pb]);.

Векторы отказа

  • Пустой catch («просто чтобы не падало»): приводит к тихой порче состояния. Минимум — логируйте и возвращайте явный fallback.
  • Смешивание доменных ошибок и AbortError: UI начинает показывать «ошибка», когда пользователь просто ушел со страницы. Отделяйте отмену.
  • Нарушение контракта функции: то возвращаете объект, то null, то кидаете исключение. Документируйте: что считается ошибкой, что — отменой, что — пустым результатом.

Для тех, кто проходит обучение javascript async await, полезный критерий качества материалов: есть ли разбор того, как не превращать await в последовательную «пробку» и как стандартизировать обработку ошибок в сценариях.

Организация очередей задач: throttling, batching и ограничение параллелизма

Риски и ограничения перед внедрением:

  • Неправильный лимит параллелизма может ухудшить время до первого результата и «заморозить» интерфейс очередью.
  • Без приоритета задачи «дальнего бэкапа» могут вытеснить задачи UI.
  • Ретраи без джиттера создают волны нагрузки и повторные пики.
  • Очередь без отмены/дедупликации копит бесполезные задачи (например, при быстрой навигации).
  1. Определите единицу работы и контракт результата. Решите, что такое одна задача: запрос, группа запросов (batch) или вычисление. Сразу определите формат результата: { ok: true, value } / { ok: false, error }, чтобы частичные ошибки не ломали поток.
  2. Выберите механизм контроля нагрузки. Для UI чаще нужен throttling/debouncing, для сетевых операций — лимит параллелизма, для массовых апдейтов — batching.

    • Throttling: не чаще N раз за интервал.
    • Debounce: выполнить один раз после паузы.
    • Batching: собрать несколько операций в одну (если API поддерживает).
  3. Реализуйте лимит параллелизма (semaphore). Держите счетчик активных задач и очередь ожидающих; запускайте следующую задачу только когда освободится слот.

    function createLimiter(concurrency) {
  let active = 0;
  const queue = [];

  const runNext = () => {
    if (active >= concurrency || queue.length === 0) return;
    active++;
    const { fn, resolve, reject } = queue.shift();
    Promise.resolve()
      .then(fn)
      .then(resolve, reject)
      .finally(() => {
        active--;
        runNext();
      });
  };

  return (fn) => new Promise((resolve, reject) => {
    queue.push({ fn, resolve, reject });
    runNext();
  });
}

const limit = createLimiter(4);
const jobs = urls.map((url) => limit(() => loadJson(url)));
  4. Добавьте отмену, дедупликацию и таймаут на задачу. Если задача больше не актуальна — не держите ее в очереди. Для запросов прокидывайте signal, для вычислений — проверяйте флаг отмены.

    • Дедупликация по ключу (например, URL + параметры) предотвращает дубли при повторных кликах.
    • Таймаут «срезает» зависшие операции и освобождает слоты.
  5. Опишите политику ошибок: retry/skip/fail-fast. Для критичных цепочек используйте fail-fast; для массовых задач — allSettled и сбор ошибок. Ретраи делайте только для явно временных ошибок и ограничивайте количеством попыток.

Если вы ведете внутреннее обучение и у вас есть курс javascript для начинающих онлайн, очередь задач стоит показывать как следующий уровень после промисов: это дисциплина эксплуатации, а не «еще один синтаксис». Для команд, выбирающих курсы javascript асинхронность, важна практика именно с лимитами, иначе выпускники пишут «шквал запросов» при любом списке.

Отмена запросов и операций: AbortController, таймауты и контракт отмены

Базовый паттерн: AbortController + таймаут

function withTimeout(ms, controller) {
  const id = setTimeout(() => controller.abort(), ms);
  return () => clearTimeout(id);
}

async function fetchWithAbort(url, ms = 8000) {
  const controller = new AbortController();
  const clear = withTimeout(ms, controller);

  try {
    const r = await fetch(url, { signal: controller.signal });
    if (!r.ok) throw new Error(`HTTP ${r.status}`);
    return await r.json();
  } finally {
    clear();
  }
}

Проверка результата: чек-лист устойчивой отмены

  • Отмена отличима от ошибки: AbortError не показывает «красную» ошибку пользователю без необходимости.
  • signal прокинут во все вложенные операции (fetch/обертки/клиенты), иначе отмена частичная и вводит в заблуждение.
  • Таймаут очищается в finally, чтобы не было ложных abort после завершения.
  • После отмены состояние UI не обновляется «старым» ответом (проверка актуальности запроса/версии).
  • Очередь задач умеет снимать неактуальные задания до запуска (или помечать как cancelled).
  • Есть единый контракт: функция возвращает null (или специальный результат) при отмене либо всегда кидает исключение — но не мешает оба подхода хаотично.
  • В логах отмены не засоряют мониторинг как инциденты (фильтр по типу ошибки).
  • Есть стратегия частичных успехов: если часть данных пришла до отмены, понятно, что отображать и как откатывать.

Композиция асинхронных операций: последовательность, параллель, race и retry

Примеры композиции

// Последовательность (зависимые шаги)
const token = await loadJson("/api/token");
const data = await loadJson(`/api/data?token=${token.value}`);

// Параллель (независимые)
const [a, b] = await Promise.all([loadJson("/a"), loadJson("/b")]);

// Race (первый ответ) - осторожно: остальные операции не отменяются автоматически
const fastest = await Promise.race([loadJson("/m1"), loadJson("/m2")]);

Частые ошибки и ловушки (что ломает прод)

  • Fail-fast там, где нужны частичные результаты: Promise.all роняет весь набор при одной ошибке — используйте allSettled и собирайте отчет.
  • Race без отмены: проигравшие запросы продолжают нагружать сеть/сервер; добавляйте AbortController и отменяйте «лишние».
  • Retry на любые ошибки: нельзя ретраить 4xx/валидацию и неидемпотентные операции без специального ключа; ограничивайте попытки и добавляйте задержку.
  • Синхронные исключения в «асинхронных» колбэках: оборачивайте запуск в Promise.resolve().then(fn), чтобы не выпадать из цепочки.
  • Потеря стека и контекста: при перекидывании ошибок между слоями добавляйте метаданные (endpoint, correlation id).
  • Конкурентные обновления состояния: два запроса обновляют один store; используйте версионирование, «последний победил» по timestamp/sequence.
  • Неявные зависимости: await в цикле forEach не работает как ожидается — используйте for...of или собирайте массив промисов.

Отладка, тестирование и упрочнение асинхронного кода в продакшне

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

  1. RxJS/реактивные потоки — когда у вас много событий, отмен, переключений (typeahead, realtime, сложные UI-пайплайны) и нужна композиция потоков с отменой по умолчанию.
  2. Очереди на уровне инфраструктуры (бекенд/воркеры) — когда задачи долгие, должны переживать перезагрузки и нужны ретраи/дедуп на сервере.
  3. State machine (XState или аналог) — когда асинхронные сценарии имеют много состояний, таймаутов и ветвлений, и баги возникают из-за «не того состояния».
  4. Стандартизированные обертки клиента — когда нужно единообразие: таймауты, ретраи, логирование, AbortController, маппинг ошибок в одном месте.

В тестах проверяйте: (1) что отмена не обновляет UI, (2) что лимит параллелизма держится, (3) что частичная ошибка не ломает успешные результаты. В продакшне добавляйте корреляцию запросов и метки «cancelled/timeout» в логах — так расследования становятся короче.

Практические ответы и типичные сомнения разработчиков

Всегда ли нужно использовать async/await вместо промисов?

Нет: async/await — синтаксический сахар над промисами. Для композиции и утилит (например, allSettled, ограничители параллелизма) промисы часто выразительнее; для сценариев — удобнее async/await.

Почему try/catch не ловит ошибку внутри .then()?

Потому что try/catch ловит синхронные исключения в текущем стеке. Ошибки в промисах ловите через await внутри try или через .catch() на цепочке.

Как отменить Promise, если он уже запущен?

Нельзя отменить сам Promise, можно отменить источник операции: fetch через AbortController, таймер через clearTimeout, вычисление — через кооперативную проверку флага отмены.

Когда выбирать Promise.allSettled вместо Promise.all?

Когда вам важны частичные результаты и отчет по ошибкам (массовые загрузки, списки). Promise.all уместен, если ошибка любого элемента должна останавливать сценарий.

Какой лимит параллелизма ставить в очереди?

Универсального числа нет: начните с малого, измеряйте время ответа и нагрузку, учитывайте лимиты API и браузера. Главное — иметь лимит как механизм, а не «бесконечный параллелизм».

Почему await в forEach «не работает»?

forEach не ожидает промисы из колбэка. Для последовательного выполнения используйте for...of, для параллельного — map + Promise.all/allSettled.

Что включать в минимальный контракт сетевого клиента?

Таймаут, отмену через AbortController, нормализацию ошибок (HTTP/сеть/парсинг), и возможность получить контекст (URL, параметры, correlation id).