Вопросы на собеседовании: Node.js-разработчик

Node.js представляет собой среду выполнения JavaScript вне браузера.

• Он использует движок V8 для компиляции и выполнения JavaScript.
• Он предоставляет серверные API для файлов, сети, процессов и взаимодействия с операционной системой.
• Его событийная модель с неблокирующим вводом-выводом подходит сервисам с множеством одновременных I/O-операций.

V8 выполняет JavaScript, а libuv предоставляет event loop и кроссплатформенную поддержку асинхронного ввода-вывода.

• V8 разбирает, компилирует, оптимизирует и выполняет JavaScript-код.
• libuv координирует таймеры, готовность сетевых операций и работу, переданную в пул потоков.
• Node.js связывает эти компоненты с JavaScript API, такими как fs, timers и сетевые модули.

Это означает, что один поток event loop обычно выполняет JavaScript callbacks процесса по одному.

• Одновременные I/O-операции всё равно могут продвигаться через операционную систему и libuv.
• Часть файловых, DNS, crypto и compression операций использует thread pool libuv.
• Worker threads или child processes при необходимости дают дополнительные потоки или процессы выполнения JavaScript.

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

• JavaScript запускает работу вроде таймера или сетевого запроса и регистрирует продолжение после её готовности.
• Node.js обрабатывает очереди callbacks в определённых фазах.
• Долгий синхронный JavaScript задерживает остальные callbacks, потому что поток event loop не может выполнять их одновременно.

Основные фазы это timers, pending callbacks, внутренние idle и prepare, poll, check и close callbacks.

• Фаза timers запускает готовые callbacks setTimeout и setInterval.
• Poll получает I/O-события и запускает многие I/O callbacks, а check запускает callbacks setImmediate.
• На фазе close callbacks обрабатываются события закрытия, например закрытие сокета, а microtasks выполняются вокруг callbacks и не являются обычной фазой.

Фаза timers делает callback доступным после истечения задержки, но не гарантирует точное время выполнения.

• Задержка является минимальным порогом, а не назначенным моментом по часам.
• Предыдущая синхронная работа и другие callbacks в очередях могут отложить запуск.
• setInterval повторяет готовность через интервал, но его callbacks также задерживаются при нагрузке на event loop.

Фаза poll получает новые I/O-события и запускает готовые callbacks для многих завершённых I/O-операций.

• Она может ждать I/O, если callbacks пока не готовы и правила планирования не требуют перейти дальше.
• На время ожидания влияют таймеры и callbacks setImmediate в очереди.
• Не каждое асинхронное API завершается в poll, поэтому остальные фазы event loop тоже важны.

setImmediate планирует callback для фазы check, а setTimeout для фазы timers после минимальной задержки.

• Их относительный порядок в коде верхнего уровня нельзя считать общей гарантией.
• Если оба вызова запланированы из одного I/O callback, setImmediate выполняется в ближайшей фазе check раньше таймера с нулевой задержкой.
• Выбирайте API по нужной фазе, а не считайте любой из них командой выполнить немедленно.

process.nextTick ставит callback на выполнение после текущей JavaScript-операции и до продолжения event loop в другой фазе.

• После завершения обычного callback Node.js очищает очередь nextTick перед Promise microtasks.
• Выполнение ESM и уже начатая обработка microtasks не позволяют считать это универсальной гарантией порядка исходного кода.
• Рекурсивное планирование nextTick может задержать таймеры и I/O, поэтому оно не заменяет обычное асинхронное планирование.

Promise reactions выполняются из очереди microtasks после текущего callback или script и до продолжения другой работы event loop.

• then, catch, finally и продолжение после await планируются как microtasks.
• Microtasks не являются отдельной фазой event loop libuv.
• Длинная цепочка microtasks может задержать таймеры и I/O callbacks, хотя каждый шаг асинхронный.

Блокировка event loop не позволяет процессу выполнять другие JavaScript callbacks во время этой работы.

• CPU-heavy циклы и синхронный I/O увеличивают задержку несвязанных запросов в том же процессе.
• Неблокирующие API позволяют event loop обслуживать другую работу во время ожидания I/O.
• Крупные CPU-задачи лучше переносить в worker threads, child processes или другой сервис.

Пул потоков libuv выполняет отдельные блокирующие или CPU-intensive нативные операции вне потока event loop.

• Частые примеры включают многие fs API, dns.lookup, crypto-операции и zlib.
• Завершение передаётся обратно, чтобы соответствующий callback или Promise продолжился в потоке event loop.
• I/O сетевых sockets обычно использует готовность операционной системы, а не отдельный поток pool на соединение.

Callback это функция, переданная другой операции для вызова после завершения работы или наступления события.

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

Error-first callback получает ошибку первым аргументом, а данные успеха последующими аргументами.

• null или отсутствие первого аргумента означает успех операции.
• Если первый аргумент не равен null или undefined, ошибку обычно нужно обработать или передать дальше.
• Многие старые Node.js API используют форму callback(error, result), которую можно адаптировать к Promise через promisify.

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

• Именованные функции и ранние возвраты делают callback-код более плоским.
• Promise выражают последовательности через возвращаемые цепочки и общую обработку catch.
• async и await дают синтаксис, похожий на последовательный, сохраняя асинхронность Promise.

Promise находится в состоянии ожидания pending, пока не завершится успешно fulfilled или с отклонением rejected.

• Fulfilled и rejected являются двумя завершёнными settled-состояниями.
• После завершения Promise не может изменить состояние или результат.
• Обработчики можно добавить до или после завершения, и они всё равно выполнятся асинхронно как microtasks.

then обрабатывает fulfillment, catch обрабатывает rejection, а finally запускает код очистки после любого исхода.

• Каждый метод возвращает новый Promise, позволяя продолжить композицию.
• Возвращённое обработчиком значение переводит следующий Promise в fulfilled, а выброшенная ошибка отклоняет его.
• finally обычно сохраняет предыдущее значение или ошибку, если его callback не выбросит ошибку и не вернёт rejected Promise.

Возврат из обработчика then связывает его результат со следующим Promise в цепочке.

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

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

• Promise.all сохраняет порядок входов в массиве успешных результатов.
• Его раннее отклонение не отменяет автоматически остальные запущенные операции.
• allSettled возвращает объекты status для fulfilled и rejected входов, что полезно, когда важен каждый результат.

Async-функция всегда возвращает Promise своего будущего результата.

• Возврат обычного значения успешно выполняет этот Promise со значением.
• Выброшенная внутри функции ошибка отклоняет возвращаемый Promise.
• Тело функции может использовать await для приостановки собственного продолжения без блокировки потока event loop.