Виконання певних операцій в програмуванні може бути блокуючим, або неблокуючим.
Блокуючі операції призупиняють виконання коду в потічку, тому якщо нам потрібно виконувати декілька таких операцій, наприклад, прийняти дані через інтернет від кількох користувачів, то продуктивність роботи серверу буде дуже низькою, адже поки він обробляє дані від одного користувача, решта даних повинна чекати.

Аби пофіксити це, люди вигадали дуже просте рішення - а давайте будемо створювати по потічку на кожного користувача/ресурс, тоді операції, що стосуються окремих користувачів будуть виконуватись в окремих потічках, паралельно, і не будуть блокувати одне одного.

Такий підхід працює, але блокуючі операції можуть займати дуже багато часу, і під час цього часу нічого не відбувається, тому виходить так, що кожен потічок за всю тривалість свого життя може дуже багато часу просто стояти без діла, і в ньому нічого не відбуватиметься, але при цьому кожен потічок вимагає значних ресурсів, як от оперативної пам'яті, тому з таким підходом дуже багато ресурсів використовується на простоювання.

Яке наступне можливе рішення? - Перевірка статуса ресурсу!

Уявімо собі, що кожен ресурс, на котрому виконується блокуюча операція (таким ресурсом може бути сокет, якщо ми зчитуємо дані передані через інтернет, або файл, з котрого ми намагаємось прочитати дані) - має певну інформацію про те, що з ним зараз відбувається. Наприклад, коли дані були отримані, і сокет вже може їх повернути, то одне з полів всередині сокету, наприклад, STATUS, буде мати певне значення, котре повідомляє нас, що ми можемо прочитати дані.

Тепер, якщо в нас є декілька таких сокетів, то ми можемо створити вічний цикл, котрий перевіряв би значення поля STATUS в кожному сокеті, і якщо це поле повідомляє нас про те, що ми можемо прочитати дані - то ми їх читаємо і обробляємо, після чого цикл продовджується.

Плюсом такого підходу є те, що нам потрібен лише один потічок, в котрому крутився б цей цикл, але мінусом є те, що весь той час, коли дані не є готовими для читання, цей цикл все одно працює, перевіряючи поле STATUS кожного ресурса, а це забирає потужності процесора, і виходить так, що процесор працює, але більшість часу він нічого корисного не робить...

І тепер ми наблизились до того, як подібні речі працюють в NodeJs.

Ми й досі використовуємо один потічок, але також ми використовуємо систему подій, або ж повідомлень.
Справа в тому, що в сучасних операційних системах є можливість очікування певних подій, що відбуваються "на" ресурсах. Наприклад, коли дані готові для прочитання з сокету, або файлу на диску, то операційна система створює повідомлення про цю подію, і заносить його в певну чергу.
NodeJs може звернутись до операційної системи, аби та повернула ті повідомлення (що вже є в черзі) (при цьому повернуті повідомлення видаляються з черги, тому NodeJs завжди отримуватиме свіжі повідомлення).

Сама операція отримання цих повідомлень є блокуючою, тобто, коли ми просимо ОС повернути нам інформацію про повідомлення з черги, то код зупиняється доти, доки ОС не поверне цю інформацію, і тільки після цього код продовжить працювати.
Коли інформація про повідомлення отримана, то ми просто обробляємо її, і коли обробка закінчилась, то ми знову просимо ОС повернути нам інформацію, вже про нові повідомлення.

Псевдокод може виглядати ось так

while (events = OS.pleaseGiveEvents()) { // блокуюча операція
   forEach(event in events) { // проходимось по масиву з повідомленнями
    handleEvent(event); // і обробляємо кожне повідомлення
  }
}

Тепер, допоки ОС не поверне нам інформацію про події/повідомлення - наш код нічого не робить (і не навантажує процесор), але як тільки нові повідомлення з'являються, то усі вони швиденько обробляються. Все це відбувається в одному потоці.

Подібна обробка повідомлень/подій називається event demultiplexing - демультиплексія подій, суть її в тому, що ми отримуємо повідомлення з різних місць (різних ресурсів), але обробляємо їх в одному місці.
А патерн проектування, що використовує цю фічу, називається Реактор.  https://en.wikipedia.org/wiki/Reactor_pattern
А в NodeJs ця фіча називається event loop (але то всьо спрощено, звісно ж).

Прочитав був про те, як відбувається імпортування модулів в Node.Js з використанням функції require.

Виявляється, що коли ми імпортуємо модуль

const myModule = require('./myModule');

То всередині функції створюєтся об'єкт

const module = {
 exports: {},
 id
}

Як бачите, цей об'єкт містить два поля - exports та id
перше поле міститиме все те, що ми експортуємо з модуля, а друге є ідентифікатором модуля, аби ми потім змогли знайти його в кеші.
Далі цей об'єкт module відправляється аргументом в функцію, котра містить користувацький код, і всередині цієї функції об'єкт module.exports наповнюється тими речами, які ми хочемо експортувати

// файл myModule.js
module.exports = { name: 'FakiNyan', sayHi: function() { console.log(`Hi, ${this.name}`) } };

І тепер, в іншому файлі я зможу імпортувати цей модуль, та виконати функцію sayHi наступним чином

const myModule = require('./myModule');
myModule.sayHi(); // виведе "Hi, FakiNyan"

Але ж ви розумієте, що користувацький модуль myModule.js може також спробувати імпортувати інші модулі, і для цього йому потрібна функція require, тому вона також передається в функцію разом з об'єктом module.

При цьому в коді файлу myModule.js ми не бачимо ніякої функції, котра б отримувала якийсь require та module як аргументи, але вона є!
Це відбувається автоматично, і це можна легко довести, якщо в файлі myModule.js додати код

console.log(arguments);

arguments - це масив аргументів, котрі передаються в функцію, він явно не описується як аргумент функції, але він є.

console.log вище виведе нам інформацію про аргументи, котрі неявно передались в функцію, котра так само неявно та автоматично огорнула код нашого модуля.
Перший аргумент - це об'єкт module.exports, другий аргумент - функція require, третій аргумент - просто об'єкт module (так, в функцію передається як поле об'єкту module - exports, так і сам об'єкт module), а наступними аргументами будуть шлях до файлу модуля, та шлях до директорії, в котрій знаходиться модуль.

А тепер найцікавіше... Два модулі можуть імпортувати один одного, таким чином утворюється цикл.
Нехай маємо модуль a.js з наступним кодом

exports.loaded = false;
const b = require('./b'); 
module.exports = {
  bLoaded: b.loaded,
  loaded: true,
};

І модуль b.js з таким кодом

exports.loaded = false;
const a = require('./a');
module.exports = {
  aLoaded: a.loaded,
  loaded: true,
};

Увага, питання.
Що виведеться в консолі, якщо ми виконаємо наступний код.

let a = require('./a');
let b = require('./b');

console.log(a);
console.log(b);

Тепер дещо про те, для чого модулі треба, та як їх можна використовувати.
Мета модулів - створення замкнутих систем, котрі можуть інкапсулювати в собі купу різних речей, але при цьому надавати дуже простий, маленький та зручний інтерфейс та виконання певних функцій. В ідеалі кожен модуль повинен робит щось одне, і робити це добре. Такий підхід дозволяє створювати прості в підтримці шматки коду, котрі легко тестувати, та комбінуючі які з іншими подібними модулями можна створювати досить складні системи, котрі при цьому будуть гнучкими, адже вони складатимуться не з одного шматку дуже складного коду, а з багатьох маленьких шматків коду - модулів.
Це, до речі, є філософією UNIX.

Наступний приклад показує, що модуль містить деяку кількість приватних змінних та функцій, котрі не є доступними ззовні, та повертає лише одну функцію -

calculate

. Модуль можна розглядати як велику чорну коробку, в котрій багато механізмів, а цю частину

module.exports = {
  calculate,
};

як кнопку на цій коробці, натискаючи на котру механізми в коробці починають щось робить, таку кнопку ще можна назвати "інтерфейсом", або щ API - application programming interface.
Використовується даний модуль наступним чином.

const a = require('./a');

console.log(a.calculate(2, 3)); // Result is:  5

Погодьтесь, дуже просто, але навіть тут нам потрібно знати, які саме поля будуть міститись на тому об'єкті, що повертає модуль (в цьому випадку цей об'єкт зветься a, а єдине поле на ньому - calculate, котер є функцією).

Подібний модуль можна спростити. Наступний патерн називається на честь людини, що створила його substack.

Ідея в тому, аби повертати якомога менше інформації з модуля, і аби вона була в такому форматі, котрий дозволяє легко та швидко використовувати ОСНОВНИЙ функціонал модуля.

// модуль addition.js
const message = 'Result is: ';
const addition = (a, b) => a + b;
const format = (a, b) => `${message} ${addition(a, b)}`;

addition.format = format;

module.exports = addition;

// головний файл
const addition = require('./addition');

console.log(addition(2, 3));
console.log(addition.format(2, 3));

Як бачите, я змінив назву модуля, аби вона відповідала функціоналу цього модуля, так набагато легше розуміти, що воно має робить, і як ним користуватись.
При цьому з самого модуля я відразу експортую головну функцію - addition, а не об'єкт з полем addition, значення котрого було б тією функцією.
Тепер користувачу не треба думати про поля, а треба просто відразу виконати функцію, і отримати результат.
Я також змінив ім'я функції calculate на format, тому що це ім'я більше відповідає тому, що вона робить, та додав цю функцію на функцію addition. Таким чином користувач відразу має доступ до основного функціоналу модуля, а якщо йому треба більше, то він все одного може використати функцію format, але для цього вже треба зазирнути в документацію.

Додам ще, що модулі можуть засирати глобальний простір та змінювати (патчити, або ж латати) інші модулі, це зветься monkey patching, але такого краще не робити (хіба що під час тестування може бути корисною ця фіча)

Ще трішки розповім про те, як обробляються помилки в колбеках та EventEmitter'ах.

Як ви зрозуміли, оті колбеки виконуються деінде, але точно не в тому ж контексті, що й та функція, котра його викликатиме.
Тому подібний код не обробить помилку.

function asyncFunction() {
  setTimeout(() => {
    throw Error('Дідько!');
  });
}

try {
  asyncFunction();
} catch (err) {
  console.log(`Ми отримали помилку: ${err.message}`);
}

а покаже огидне повідомлення

/home/fakinyan/node/modules/app.js:28
    throw Error('Дідько!');
    ^

Error: Дідько!
    at Timeout._onTimeout (/home/fakinyan/node/modules/app.js:28:11)
    at listOnTimeout (node:internal/timers:555:17)
    at processTimers (node:internal/timers:498:7)

Аби перехопити цю помилку, нам потрібно огорнути в try catch безпосередньо саму функцію, в котрій виникає помилка.
При цьому в середовищі nodejs є загальноприйнатим створювати колбеки такими, аби першим аргументом, що вони приймають, була саме помилка, а далі вже результат роботи якоїсь функцію.

function asyncFunction(callback) {
  setTimeout(() => {
    try {
      throw Error('Дідько!');
    } catch (err) {
      callback(err);
    }
  });
}

asyncFunction((err, result) => {
  if (err) console.log(`Ми отримали помилку: ${err.message}`);
});

Ми отримали помилку: Дідько!

Як бачите, тепер помилка файно обробилась.

*****************************

В EventEmitter'ах все працює трішки інакше. Ми не передаємо помилку першим аргументом в колбек, бо не маємо колбеку, натомість ми відправляємо помилку за адресою "error"

function asyncFunction() {
  const emitter = new EventEmitter();
  setTimeout(() => {
    try {
      throw Error('Дідько!');
    } catch (err) {
      emitter.emit('error', err);
    }
  });
  return emitter;
}

asyncFunction().on('error', err =>
  console.log(`Ми отримали помилку (EventEmitter): ${err.message}`)
);

Ми отримали помилку (EventEmitter): Дідько!

Але обов'язковою умовою є створення "отримувача" помилки, що відправляється за адресою "error". Якщо його не буде, то така помилка ніяк не обробиться, та ми знову отримаємо огидне повідомлення в консолі, і додаток перестане працювати.

function asyncFunction() {
  const emitter = new EventEmitter();
  setTimeout(() => {
    try {
      throw Error('Дідько!');
    } catch (err) {
      emitter.emit('error', err);
    }
  });
  return emitter;
}

asyncFunction();

node:events:304
      throw er; // Unhandled 'error' event
      ^

Error: Дідько!
    at Timeout._onTimeout (/home/fakinyan/node/modules/app.js:30:13)
    at listOnTimeout (node:internal/timers:555:17)
    at processTimers (node:internal/timers:498:7)
Emitted 'error' event at:
    at Timeout._onTimeout (/home/fakinyan/node/modules/app.js:32:15)
    at listOnTimeout (node:internal/timers:555:17)
    at processTimers (node:internal/timers:498:7)

Троха температура спала, вирішив написати дещо про послідовне виконання асинхронних завдань.
Нагадаю, що асинхронні функції, це ті функції, котрі закінчують своє виконання через деяких час, тому ми не можемо викликати таку функцію і відразу отримати результат, ми маємо почекати, і так, як функція закінчує своє виконання в іншому контексті, в контексті циклу подій, то ми не маємо доступу до результату її виконання.
Щоб отримати той доступ, ми передаємо іншу функцію - колбек (callback) в нашу асинхронну функцію, і коли асинхронна функція закінчила своє виконання, то "система" автоматично викликає наш колбек, передаючи в нього помилку, якщо така є, і результат виконання асинхронної функції, якщо такий є.

Уявімо, що нам потрібно виконати декілька речей по черзі, тобто, спочатку виконується перша функція, потім друга, а потім третя. Такий код може виглядати наступним чином.

const tasks = ['Прокинутись', 'Попоїсти', 'Попрацювати'];

function runTask(taskName, callback) {
  console.log(`Старт. ${taskName}. ${new Date().getSeconds()}`);
  setTimeout(() => {
    console.log(`Фініш. ${taskName}. ${new Date().getSeconds()}`);
    callback(null);
  }, 1000);
}

runTask(tasks[0], err => {
  runTask(tasks[1], err => {
    runTask(tasks[2], err => {
      console.log('Кінець!');
    });
  });
});

1. Спочатку я створив список наших завдань
2. Функція runTask є саме тою асинхронною функцією, котра виконує якусь роботу, та закінчує виконання асинхронно. Старт сигналізує початок роботи, а фініш - кінець. Робота займає одну секунду.
3. Далі я викликає функцію передаючи в неї першу роботу з масиву робіт, при цьому передаю в нею колбек, котрий виконається лише після виконання першого виклику функції runTask. В цьому колбеці я викликаю ту саму функцію, але з іншим завданням, і так само ще раз.

Примітка: callback(null) та err всередині функцій додані спеціально, тому що за конценцією колбеків NodeJs першим аргументом колбеку повинна бути помилка, якщо така є. callback(null) як раз сигналізує, що помилки немає. Після неї я міг би передати ще якісь аргументи, котрі були б результатом виконання функції, але в цьому прикладі результату немає, тому я нічого не передаю.

Результатом виконання всього цього коду буде:

Старт. Прокинутись. 17
Фініш. Прокинутись. 18
Старт. Попоїсти. 18
Фініш. Попоїсти. 19
Старт. Попрацювати. 19
Фініш. Попрацювати. 20
Кінець!

Як видно з тексту та значення секунд - завдання виконується одне за одним, і виконання кожного завдання займає одну секунду.

Але уявімо, що у нас є дуже багато таких завдань, тоді такий код може швидко перерости в те, що в народі називається - пекло колбеків (callback hell), і виглядати воно може ось так.

Погодьтесь, виглядає воно так собі, прочитати цей код досить важкувато, а головне, що з часом, ширини монітору може не вистачити.

Ну і останнім прикладом послідовного виконання асинхроних завдань буде приклад з асинхронними генераторами...

function runTask(taskName) {
  console.log(`Старт. ${taskName}. ${new Date().getSeconds()}`);
  return new Promise((resolve, reject) => {
    setTimeout(
      () => resolve(`Фініш. ${taskName}. ${new Date().getSeconds()}`),
      1000
    );
  });
}

async function* runAllTasks() {
  yield await runTask(tasks[0]);
  yield await runTask(tasks[1]);
  yield await runTask(tasks[2]);
  yield await Promise.resolve('Кінець!');
}

(async () => {
  for await (let _ of runAllTasks()) {
    console.log(_);
  }
})();

Старт. Прокинутись. 35
Фініш. Прокинутись. 36
Старт. Попоїсти. 36
Фініш. Попоїсти. 37
Старт. Попрацювати. 37
Фініш. Попрацювати. 38
Кінець!

Щоб пояснити, що тут відбувається детально, піде багато часу, бо сам концепт генераторів є досить цікавим, тому поясню коротко.

В циклі for, з функції-генератору runAllTasks ми отримуємо спеціальний об'єкт, котрий містить в собі функцію next. Ця функця повертає об'єкт у форматі

{value: якесь значення, done: true, або false}

value є тим значенням, котре ми повертаємо за допомогою ключового слова yield, ну а done просто сигналізує, чи цикл можна завершити.

Далі, сам цикл for викликає цю функцію next, та заносить значення, котре вона повертає, в змінну _ (я назвав її так, бо спершу не хотів її використовувати, а потім передумав, але змінювати її назву на щось нормально вже ліньки), після чого ми просто консоль.логаємо це значення.

Важливо зрозуміти, що це саме асинхронний генератор, бо є і синхронні.
Особливість асинхронного генератора в тому, що значення, котрі повертаються з next, можуть приходити з затримкою (тому і асинхронні), і весь цей час наш цикл буде чекати на це значення, і лише після того, як отримає його, викличе функцію next знову.
Таким чином у нас є досить красивий спосіб виконувати певні завдання одне за одним.