Node.js Recipes

Сьогодні хочу поділитися одною із email-розсилок, які регулярно читаю – це Simon Wilson Newsletter. Якщо ви віддаєте перевагу RSS чи блогам, можете читати й так – simonwillison.net

У Саймона класний контент, присвячений LLM/AI та інструментам, який він створює для них.
Ось інструменти, які потрібно знати:
- https://github.com/simonw/llm - Access large language models from the command-line
- https://github.com/simonw/files-to-prompt - Concatenate a directory full of files into a single prompt for use with LLMs
- https://github.com/simonw/sqlite-utils - CLI utility for manipulating SQLite databases

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

За замовчуванням Node.js використовує лише одне ядро, але ми можемо використовувати Worker threads або Child Process.
Якщо ви їх використовуєте, настійно рекомендую під час запуску програми перевіряти кількість доступних ядер для вашого застосунка. Таким чином ви гарантуєте, що програма матиме необхідну кількість ресурсів. Наприклад, DevOps не забув внести зміни у deployment файл для Kubernetes.

Приклад коду

import { availableParallelism } from ‘node:os'; // Node 18.4+
const vCPUs = availableParallelism();
if (vCPUs < 2) throw new Error(`Minimum 2 vCPUs is required`);

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

docker run --rm --cpus=1.5 node:22-alpine node -e "console.log(require('os').availableParallelism())"

Звісно, ми можемо зробити це через /sys/fs/cgroup/cpu файли щоб отримати дробове значення, але це вже OS specific

Как це буде працювати?
Контейнер може одночасно запускати 2 потоки, але в сумі за 100 мс не повинен перевищувати 150 мс процесорного часу інакше Linux throttling починає «гальмувати» процеси всередині контейнера, знижуючи їх пріоритет. Ось щоб у нас не було throttling, нам й потрібно перевірити availableParallelism.

👩‍💻 Відкрит набір на AWS She Builds Mentorship Program 2025!

Це безкоштовна глобальна програма 1:1 менторства для жінок у tech. Це програма вже не вперше та я чув позитивні відгуки.
Тут тебе поєднають із досвідченими менторками та менторами з AWS, щоб допомогти:
✅ Прокачати кар’єру
✅ Знайти свій вектор розвитку
✅ Отримати підтримку в реальному світі технологій

📅 Тривалість: 12 тижнів (1 вересня – 28 листопада 2025)
🕓 Дедлайн подачі: 30 червня
🌍 Участь — онлайн, з будь-якої точки світу

🔗 Подати заявку: тут
📌 Умови: для жінок 18+, які навчаються, працюють або хочуть увійти в сферу технологій

Так, я знаю, що більшість читачів каналу не відповідають критеріям цієї програми. Для вас, шановні колеги, я рекомендую прочитати книгу 12-тижневий рік. Саме стільки триватиме вищезгадана програма. Повірте, якщо ви будете застосовувати ідеї з цієї книги, то навіть без жодного наставника зможете прокачатися у AWS чи яку мету ви оберете.

Як і навіщо перевіряти, що код запущено під потрібною версією Node.js?
#nodejs_api

Використання нових можливостей nodejs або сучасного синтаксису мови може призвести до того, що ваш застосунок не запуститься на застарілій версії Node.js. Тому варто перевіряти версію Node.js і кидати необроблену помилку, якщо код запущено під неправильною версією. Робити це потрібно у файлі входу (entry point), з якого запускається все застосування. Таким чином ви гарантуєте, що середовище, в якому розробляється ваш код і яке буде використовуватися на інших оточеннях чи комп'ютерах інших розробників, буде те саме.

Приклад коду:

const expectedVersion = '22.16.0';
if (process.versions.node !== expectedVersion) throw new Error(`App requires node.js version ${expectedVersion}`);

Під час оновлення версії Node.js ми змінюємо expectedVersion у коді, Dockerfile і GitHub actions.

PS Це повтор рецепту від 2021 року.

Гарне відео з типовою задачею, яка буваю підчас розробки та її має вміти виконувати TypeScript Dev. Такого рівня задачу під час live coding я відаю на співбесіді для Middle та вище рівня.
Цікавий факт: AI робить такі речі лише тоді, коли йому прямо це вказати як окреме завдання. За замовчуванням він або використає any, або взагалі почне писати свої типи замість повторного використання бібліотечних.

Хочу поділитися з вами незручною правдою. Бізнесу не потрібні:
- фреймворки
- системи логування
- CI/CD
- тестування
- i так далі.

Ці процеси та інструменти потрібні нам, інженерам, щоб якісно виконувати свою роботу.

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

Ще раз, це ваше завдання - знати документацію, знаходити час для оновлення технічного стеку або погашення технічного боргу. Знаходити баланс між технічними завданнями і впровадженням бізнес-фіч – це ознака Senior-а.

PS Пост написаний за підсумками обговорення з менті питання “Як отримувати від бізнесу апруву на технічні завдання?”. Контекст: менті - єдиний розробник у проєкті. Моя позиція, як ви вже здогадалися з допису, не обговорювати це питання з бізнесом, а просто виділяти 2 години кожен робочий день на технічні завдання.

Поділюсь своїм баченням поточних реалій ринку.

Зараз основна складність з наймом інженерів – не через дефіцит кандидатів, а навпаки: на ринку надлишок претендентів, і більшість з них не відповідають очікуванням.

Основні проблеми:
- Велике навантаження на рекрутинг – потрібно переглянути сотні резюме, щоб знайти хоча б одного сильного кандидата.
- Якісні фахівці рідко шукають роботу – у нестабільних умовах вони не хочуть ризикувати стабільними проєктами.
- Оптимізація під вакансії – багато хто «прокачує» резюме під вимоги (читай: прикрашає факти).
- AI-чітінг – використання штучного інтелекту для виконання тестових і навіть під час технічних співбесід без розуміння відповідей.

⚠️ Ця ситуація характерна як для українського, так і для міжнародного ринку.

Що з цим доводиться робити?
У межах консалтингу я додаю тестове завдання до технічної співбесіди. Рекрутер попереджає, що буде розгорнутий фідбек за результатами. Нижче – статистика за 2025 рік за двома вакансіями: Senior FullStack і Senior Node.js Developer.

- Взяли тестове завдання – 17 кандидатів (із них задали уточнювальні питання – 3)
- Прислали виконане завдання – 11
- Завдання виконано на рівні Senior – 4
- Завдання виконано на рівні Middle – 2
- Зроблено оферів за підсумками співбесід – 1

Основні проблеми в тестових:
👎Додаток не запускається або не збирається.
Приклад: конфлікти версій бібліотек.
👎Обрано невдалий архітектурний підхід або технологічний стек.
Приклад: реалізація real-time (WS/SSE) у NestJS без використання RxJS.
👎Відсутні важливі фічі.
Приклад: у FullStack-завданні була явна задача на sharing у соцмережах, але її не реалізували бо use client
👎Ігнорування базових best practices.
Приклад: захардкожені змінні замість використання env vars, потенційні security-уразливості.

Основні проблеми під час обговорення тестового на технічній співбесіді:
🤦‍♂️Кандидат не може пояснити прийняті рішення або власний код.
🤦‍♂️Кандидат не здатен внести правки у свій код.
Приклад: “Давайте виправимо цей незначний баг” – і починається паніка.

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

З коментарів:

приємний сюрприз що sqlite розглядається як частина стд бібліотеки

Мій коментар:

Ми можемо спостерігати конкуренцію між JS runtime'ами: NodeJS vs Bun vs. Dino.
Це добре, бо саме через цю конкуренцію ми й надалі будемо спостерігати додавання пакетів у Node.js core, як це було з undici, SQLite, env-file.
Наприклад, Bun надає SQL/Redis/S3/etc, а Deno – OpenTelemetry. Тому скоро ми можемо побачимо деякі з цих залежностей у Node.js.

Якщо подивитися на те, що виходить у Bun/Deno, це дуже нагадує Ruby on Rails, коли runtime та framework це одне й теж. Node.js також рухається в цьому напрямку, але значно повільніше, забираючи з того, що вже є. Мені здається, що це правильний напрямок, тому що це покращується DevEx.

Колеги, хочу попросити вас заповнити Node.js Next 10 Survey, яке регулярно проводить Linux Foundation.
На основі цих даних команда Node.js Core визначає пріоритети розвитку нашого основного інструменту.
По суті, вони намагаються сформувати бачення розвитку Node.js на найближчі 10 років.
Подивитися результати минулорічних опитувань можна в цьому репозиторії

У коментарях запитали:

Чи має для поради літературу для формування правильного мислення, щоб рухатись у напрямку архітектора

Зверніть увагу, що архітекторів буває багато різних типів
- архітектор, зосереджений на пресейл-активностях, повинен також мати навички в продажах.
- архітектор, який виконує функції R&D-інженера, буде писати багато нового/складного коду.
- архітектор, що виконує роль техліда, відповідатиме за внутрішній framework та code review

🎓 Домовимось про терміни.
Для мене позиція архітектора - це переклад продуктової візії в технічне бачення. Це саме те, від чого я кайфую.
Такому архітектору потрібно cбирати вимоги, знаходити сліпі зони або пропонувати щось самому.

Ось топ-5 компетенцій для такого архітектора:
1️⃣ Product mind set – українською мовою дуже класно @product_borsch
2️⃣ Технологічний стек. Звичайно, у вас буде улюблений toolset, but don’t be merried with that. Тому потрібно вміти читати код на кількох мовах. Критерієм "розбираюсь/не розбираюсь" є здатність написати Architecture Decion Record щодо вибору технічного стека для нової функції. Використання GPT-чату або інших експертів - це нормально
3️⃣ DevOps/CloudNative – бери одну хмару і розбирайся в ній досконало. Якщо необхідно перейти на іншу, це не проблема. Сертифікати допомагають у "Зробив/Не зробив".
4️⃣ Діаграми та архітектурні шаблони. Основні артефакти роботи архітектора, як й Architecture Decision Record.
5️⃣ Останнє у списку, але найважливіше. Вміння переключатися між рівнями. Приклад https://fwdays.com/en/event/architecture-fwdays-2023/review/exploring-mach-principles

За кожною з компетенцій рекомендую надіслати запит на deep research в кілька LLM та ви оберете те, що вас зацікавило. До речі, саме цей AI-інструмент я найчастіше використовую як архітектор.

У коментарях запитали:

нащо потрібні 10 сіньйорів якщо ту саму работу можуть з ші зробити 3 от нащо хтось може пояснити? =)

🎓Для тих, хто не вчив економіку: що таке парадокс Джевонса?
Коли з’являється технологія, яка робить щось ефективніше (дешевше, швидше, з меншими затратами) – попит на цю річ… зростає, а не падає.
Парове вугілля стало ефективнішим – його почали використовувати більше, не менше.
AI зменшує вартість коду – значить, будуть хотіти більше коду, а не менше.

👉 То чому ж потрібні 10 сеньйорів?
AI не скорочує попит на інженерів – він відкриває нові юзкейси, які раніше були занадто дорогими або складними.
Бо змінюєтся сам підхід до розробки.
Раніше бізнес купував готовий SaaS і підлаштовував під нього процеси.
Тепер він може найняти одного програміста з ChatGPT – і отримати свій внутрішній продукт, який автоматизує саме його бізнес-логіку.
Не підлаштовуватись під софт, а писати софт під себе.

💪AI не замінює сеньйорів – він масштабує їх вплив.
І тому 10 сеньйорів будуть потрібні ще більше, бо тепер замість одного корпоративного рішення буде 3 кастомних, автономних, гнучких продуктів – кожен з яких треба спроєктувати, реалізувати і підтримувати.

🧠 Ще раз: AI не прибирає людей – він прибирає лінивих та інфантильних.
Сеньйори (не за вислугою років, а за майндсетом) залишаться, бо саме їх мозок і judgment потрібні більше, ніж коли-небудь.

Останні два тижні в AI — новий виток. Вийшла купа моделей і тулзів для девелоперів. Потестити все ще не встиг, але знову чую: «AI забирає роботу джунів». І це жах, бо тоді хто стане сеньорами?

🟡 Непопулярна думка:
- Досвідчений джун - це не сеньор.
- Досвідчений сеньор - це не архітектор.
- Досвідчений архітектор/техлід - це не СТО.

Це не грейди одного шляху, це різні набори компетенцій.
Їх неможливо опанувати, просто «доростаючи» - їх треба перемкнути свідомо, змінюючи підхід, зони відповідальності та перспективу.

🧠 Ключова думка:
Сеньори з’являються не з джунів, а з недосвідчених сеньорів.
СТО з’являються не з архітекторів, а з недосвідчених СТО.

Кілька свіжих прикладів
1️⃣ Node.js девелопер, який 5 місяців шукає роботу сеньора. Я звів його з рекрутером, він провалив навіть базову комунікацію.
Його аргумент: «Ну, для HR комунікація - це головне, а для мене - допоміжне». Але це і є проблема: сеньор - це передусім про ефективну командну взаємодію.
2️⃣ Колега, що скаржиться, як його “недооцінили” на system design інтерв’ю. Йому пощастило, йому дістався завдання зробити систему, яку він уже робив для мільйонів користувачів. Але… забув зібрати вимоги, не продав ідею, не доніс цінність.
Архітектор – це не про те, що ти вже колись робив. Це про те, як ти комунікуєш свою експертизу тут і зараз. Інтерв’ю – це теж робоча ситуація.

AI не забирає роботу. Він просто більше не дає ховатися за «ще рано», «я не впевнений», «мені не дали шанс».
У сильних – це інструмент, а у інфантильних – конкуренція.

Учора Google анонсував AI coding agent Jules. Реєстрація на Beta уже відкрита. Під капотом використовують Gemini.2.5. Я поки що чекаю доступу.
UPDATE: Е-мейлу не було, але через 3 години доступ вже з'явився, тому замінив скріншот.

Для реального тестування, базових лімітів до 5 задач на день, ймовірно, мені не вистачить. Тому потрібно буде запитувати їх підвищення.

Ще вчора OpenAI також надав доступ до Codex у Teams.
Тому, можливо, я їх буду тестувати разом на одному і тому ж обсязі задач.

Чому це важливо? Тому що підтримка TypeScript/Node.js часто з'являється першою у AI Coding Agents.

Як AI змінює інтернет?

Десятиліттями інтернет працював за простою моделлю: користувач → пошуковик → сайт. Люди отримували відповіді, сайти – трафік, а творці контенту мали стимул створювати більше. Саме так і працював вільний веб.

Але генеративний AI (ChatGPT, Gemini, Claude) змінює гру: відповіді з’являються без переходів на сайти. Контент поглинається, але нічого не повертається авторам – ні переглядів, ні грошей.

Парадокс:
✍️ Ручне створення якісного контенту – дороге і повільне
🤖 Генеровання AI-контент – швидке і дешеве, але часто поверхневе.
🧠 І при цьому, AI вчиться та генерує відповіді на основі саме ручного контенту, який створили люди – навіть якщо моделі були дистильовані чи донавчані на проміжних репрезентаціях, їхня база все одно – ручна людська робота.

Без нових джерел знань AI почне "висихати". Ми вже бачимо перші ознаки цього – контент повторюється, втрачається глибина, а сенс розчиняється.

🎯 Що робити?
Розробники краще розуміють технічні ризики, ніж бізнес. І саме ми маємо запропонувати рішення, як захистити контент у нову епоху AI:
1️⃣ Додавай структуровані дані
Використовуй schema.org, OpenGraph, JSON-LD – це робить автора видимим для пошуковиків і AI.
2️⃣ Контролюй доступ до індексації
Налаштовуй robots.txt, meta noindex, data-nosnippet – це пряме заява, що ми не хочемо, щоб нас парсили.
3️⃣ Вшивай авторство у контент
Водяні знаки, унікальні посилання, сигнатури – усе це зберігає атрибуцію навіть у відповідях AI.
4️⃣ Захищай API/site
Додавай rate limiting, ключі доступу й умови використання. Підготовка до монетизації – вже зараз.

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

🧠 VS Code стає відкритим AI-редактором

Цього тижня буде спекотно від новин для розробників: одразу дві топові конференції – Microsoft Build і Google I/O – проходять паралельно. Перша новина від Microsoft – команда VS Code оголосила:

GitHub Copilot Chat стане open source під ліцензією MIT, а ключові AI-фічі поступово інтегрують у ядро редактора.

Моя особиста думка – це продовження курсу на відкритість. Нагадаю ще 3 місяці тому Microsoft анонсувала Language Server Protocol (LSP) для GitHub Copilot, щоб спростити інтеграції в інших IDE та дати розробникам більше прозорості. У довгостроковій перспективі ці обидва кроки надають домінуючу позицію.

Чому це важливо:
- AI вже не плагін – це ядро девелопменту.
- VS Code офіційно трансформується в AI-платформу з відкритим кодом, і Microsoft запрошує спільноту долучатися
- iteration plan та FAQ.


Що далі:
– Open source Copilot Chat
– Інтеграція AI-компонентів у core VS Code
– Відкриття інфраструктури для prompt-тестування

І на завершення, вірусне зображення OpenAl acquires Windsurf

Два місяці тому на Soft Skills fwdays’25 Сергій Немчинський зробив доповідь, у якій підкреслив важливість Estimations для бізнесу. Потім ця тема активно обговорювалася в кулуарах і в LinkedIn.

Візія Сергія:

оцінювання ефективніше проводити не в story points, а в “півднях” (half-days). Таски при цьому мають бути нарізані від півдня до максимум двох днів. Якщо більше - дробити. Якщо менше - об’єднувати.

Як навчитись оцінювати? У людини один мозок — і для роботи, і для побуту. Тож оцінку часу можна (і варто) тренувати завжди. Йдеш у магазин — прикинь, скільки це займе, і порівняй реальний результат із прогнозом. Це вже практика.

Моє бачення питання Estimations:
1️⃣ Самі творці Scrum відмовились від оцінок у їхньому класичному вигляді.

Estimating tasks will slow you down. Don’t do it… No estimation at all will improve team performance over hour estimation.

Jeff Sutherland, співзасновник Scrum і автор Agile Manifesto
2️⃣Відсутність процесу оцінювання ≠ відсутність обговорення задач і усунення невизначеностей.
3️⃣Бізнесу потрібні не оцінки, а предиктабельність (predictability).
Вона досягається тоді, коли задачі дрібні, зрозумілі, і їх регулярно доставляють у продакшн.
Детальніше у книжці NoEstimates.
4️⃣Інженер може дати адекватну оцінку тільки при фіксованому бізнес-скоупі та стабільному технічному стеку. Але заморожувати скоуп і стек - це гальмувати бізнес. І майже ніхто на це не піде.
5️⃣Бізнесу справді потрібні оцінки лише тоді, коли є кілька варіантів реалізації фічі, і вибір залежить від ресурсів. Але практика показує, що краще зробити A/B тест і подивитись на реакцію користувачів, а не гадати.

Ще раз – дрібні задачі, швидкий фідбек від команди та бізнесу ось наш реальний delivery framework.
📌 До речі, практика нарізки бізнес-фіч на дрібні delivery-орієнтовані задачі існує ще з 2016 року
А з появою AI вона почала допомагати не лише бізнесу, але й інженерам, які можуть у AI tools.

👉 Резюме
Згоден із Сергієм у тому, що задачі мають бути правильно нарізані.
А от витрачати час на оцінювання — особливо в динамічному середовищі — мені здається зайвим.

Як ефективно зменшити трафік у WebSocket-додатках?

Уявіть собі, що у вашому застосунку кілька разів на секунду мають надходити повідомлення

{ “timestamp”: 1747008028, “price”: 997.538642664439 }

Як тут краще організувати серіалізацію payload-у?

1️⃣ Чому розмір payload має значення?
- Менший пакет → коротший TTFB і менше затримок.
- Економія трафіку = нижчі витрати на інфраструктуру та швидший фронтенд.

2️⃣Порівняння розмірів повідомлень
- JSON-об’єкт {timestamp, price} – 49 byte
- JSON-об’єкт {t, p} – 37 byte
- JSON-кортеж [t,p] – 29 byte
- Protobuf – 15 byte

3️⃣ permessage-deflate (RFC 7692)
- WS мають вбудоване стиснення яке активується у фазі HTTP Upgrade: браузер пропонує, сервер вирішує.
- Алгоритм — DEFLATE (zlib); стиснення «повідомлення-за-повідомленням».
Приклад

new WebSocketServer({
port: 8080,
perMessageDeflate: {
threshold: 1024, // не стискати < 1 KB
clientNoContextTakeover: true, // менше пам’яті
serverNoContextTakeover: true
}
});

4️⃣ Коли вигідно стискати, а коли ні
- Великі JSON (>1 KB) - економія 70-90%, але навантаження на CPU
- Часті дрібні котирування (< 200 😎 - економія ~0%, бо заголовок DEFLATE «з’їдає» вигоду
- Protobuf – простіше вимкнути

👉 Висновки
- Оптимізація payloads нагадує оптимізацію зберігання в MongoDB.
- Перехід з JSON-object → JSON-array → Protobuf вже зменшує пакет у ≈3 р.
- Якщо потрібна читаємість разом з помірним зменшенням трафіку - {t,p} непоганий компроміс.
- Для максимальної продуктивності в стрімах котирувань усе ще лідирує бінарний формат (Protobuf)