На дворі вже 2026 рік, але це запитання про промісифікацію і досі гуляє по різних співбесідах, здебільшого на Junior-інтервʼю. Щоб зрозуміти, як працює даний костиль, потрібно розібрати проблематику.
Callback hell
Це ситуація, коли через багато асинхронних викликів на колбеках код перетворюється на піраміду з вкладених функцій. Через це його важко читати, дебажити і нормально обробляти помилки.
В Node.js callbacks будуються наступним чином - першим аргументом приходить помилка або null, якщо її немає. А другим аргументом приходять дані і типовий метод, який використовує callback, виглядає наступним чином:
Якщо взяти цю функцію окремо, вона виглядає адекватно. Але як тільки наблизимося до реального проєкту, де може бути багато взаємозалежних викликів, починається callback hell.
Тут приходить на допомогу промісифікація
Promisification - це коли callback-based функція огортається в Promise. Тоді замість вкладених колбеків можна зручно писати .then/.catch або async/await. Зазвичай ця техніка застосовується в двох випадках:
Коли Node.js тільки зарелізив Promise - звісно, після релізу не всі бібліотеки швидко змінили своє API з callback-based до Promise, тому доводилося огортати їх таким способом, щоб було зручніше працювати.
Legacy - зараз це найчастіше використовується для обгортання різного legacy. Наприклад, в системі є метод, який писався вашим прадідом, який звичайно використовував callback-based підхід.
Це метод має 2000 рядків коду, і переписувати його ніхто не буде, а от промісифікувати, щоб уникнути колбеків, цілком можна. І дуже часто це була частина рефакторингу, так як працювати з Promise набагато простіше і приємніше. Повернемося до методу getUser, який ми розглядали на початку. Ми можемо дуже швидко зробити з нього Promise.
А тепер подивимось, як буде виглядати callback hell, якщо його промісифікувати: