Node.js Recipes

Сьогодні прийшов імейл, що мою участь у програмі AWS Community Builders продовжено на наступний рік.

Заради цікавості я зайшов подивитися в директорію, скільки у нас білдерів з України. Їх шість. У 2024 та 2025 роках не додалося жодного нового учасника. Це сумно, адже участь у програмі для людини, що створює контент щодо Cloud-ів, одна з найпростіших.
UPDATE: Виявляється, що я не правий. В коментарях знайшовся учасник програми 2025 року. Мабуть, ще не оновили директорію.

Тому пропоную вам написати за цей рік декілька одиниць контенту з AWS/Cloud в зручному для вас форматі. Щоб коли відкриється наступна хвиля заявок у січні 2026 ви мали що подати.

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

Більшість моїх записів присвячені моєму особистому досвіду, заснованому на роботі в стартапах. Проте я цікавлюся трендами, пов'язаними з enterprise, де Angular популярніший за React, а Java більше використовується, ніж Node.js.
Тому сьогодні я хочу поділитися з вами посиланням, яке буде корисним для тих, хто працює саме на enterprise проєктах.

Open Micro Frontend Platform – OpenMFP

Чим цікавий проєкт?
- запущений лише 2 місяці тому
- фінансується Європейським Союзом
- створений за підтримки компанії SAP

А ще це частина Apeiro-Reference-Architecture, де можна прочитати слоган

Unify your services from hardware to software with Kubernetes' declarative power, across any cloud and edge!

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

Ну що, панове backend-розробники, до списку інструментів Node.js/AI/CloudNative я з чистою совістю можу додати TypeSpec.
Минулого тижня Microsoft випустила TypeSpec 1.0 GA

Чому це важливо?
Розширений список 12+3 факторів включає API First Factor.
Саме TypeSpec є тим інструментом, за допомогою якого зручно та швидко дизайнити ваш API.

Тому раджу прочитати анонс і спробувати TypeSpec. Cпочатку на вашому pet проєкті, а потім, хто знає, можете інтегрувати в процеси розробки на комерційному.

Я пам’ятаю, що обіцяв зробити огляд Coding with Al конференції – обов’язково виконаю це, щойно отримаю доступ до всіх записів. Декілька виступів я ще не встиг переглянути, тому, як і ви, чекаю відкриття матеріалів.

👀Перше враження
Назва конференції Coding with AI: The End of Software Development as We Know It не зовсім відповідає змісту. 100% доповідей стосувалися власне коду. Натомість теми, без яких ми не уявляємо повного циклу розробки — постановка завдань, збір вимог, найм команди, комунікації, перевірка гіпотез, user experience, аналітика даних — фактично не розкривалися. Тому логічніше було б назвати її The End of Coding as We Know It.

⭐️Speaker, який став відкриттям
Справжнім відкриттям для мене став виступ Гарпера Ріда «My LLM Codegen Workflow at the Moment». Поки немає відео, раджу зазирнути до його блогу – там уже є частина матеріалів із презентації: Harper Reed’s Blog.

⚙️Практичний міні-флоу, який я вже впроваджую:
1. Conversational LLM ставить лише по одному yes/no запитанню за раз.
2. Після серії питань LLM генерує специфікацію у файлі spec.md.
Це допомагає швидко 🚀 уточнювати вимоги й одразу фіксувати їх у структурованому форматі.
—
UPDATE: Прислали запис. Check your email

Інформацію про хакатон оголосили на Monthly GDE Call.
Я поставив запитання: чи можна буде використовувати Genkit, чи лише ADK?
На жаль, лише ADK. Шкода, адже Genkit має підтримку TypeScript та нім в мене є продакшн-досвід
А ADK вийшов лише місяць тому і поки що доступний тільки для Python.

📢 ADK Хакатон від Google Cloud

Відкрито реєстрацію на Agent Development Kit Hackathon. Учасники будуть створювати мультиагентні системи для вирішення задач у сферах автоматизації процесів, взаємодії з клієнтами, генерації контенту та ін.

💼 Призовий фонд: $50,000
📅 Подання заявок: з 12 травня по 23 червня 2025 року

🛠 Спробувати ADK можна вже зараз.
ℹ️ Повна інформація про хакатон з’явиться наступного тижня.

Сьогодні у нас на каналі новий формат #Smells_Like_Failure.

Правило гри: я викладаю контент, який на перший погляд здається правильним, але в ньому є концептуальна помилка. Коментар з першим правильним описом помилки отримує підписку на JetBrains IDE.

Сьогодні контент — це LinkedIn пост, який я знайшов у себе в стрічці.
—
У нас є переможець!
Рекомендація другові мала бути такою:
Слухай, я бачу за часом відповідей від сервера, що у вас не налаштований кеш для AI запитів. Ви можете витратити багато грошей, якщо будуть надсилатися одні й ті ж запити. Додавання кешу дозволить вам бути більш економними.

Через два дні стартує віртуальна конференція від O’Reilly – Coding with Al: The End of Software Development as We Know It. Контент - як це часто буває зараз – предзаписаний і буде транслюватися у стрімі.

Ось три причини, чому я буду дивитися:
1️⃣ Гаряча тема і гучні імена. Спікери – ті, хто формує тренди. Той самий Едді Асмані не потребує представлення.

2️⃣ Формат – лайтнінг-доповіді. Не затяжні 45 хвилин, а короткі, концентровані виступи. Це набагато складніше, ніж здається – за кілька хвилин донести суть без права на помилку.

3️⃣ Класна підбірка рекомендованої літератури. Все заточено під O’Reilly-каталог, а 10-денного безкоштовного тріалу вистачить, щоб осилити одну-дві топові книги. Та й, будемо чесні, вас не треба вчити, як обійти обмеження 😏

🎥 Якщо пост набере 100 вогників – зроблю відеоогляд найцікавішого з конференції.

Я дивлюсь – приєднуйтесь

Ось ще один цікавий скріншот. Колега з США тестує моделі цим промптом (підкресленим червоним), щоб перевірити, наскільки модель ерудована. На скріншоті використовується terminal з llm.datasette.io

Цікава переписка про learning by doing в сучасних умовах.

Хочу нагадати вам про дві речі:
1️⃣ Маніфест 12 факторів говорить: Store config in the environment
2️⃣ process.env — це не звичайний JavaScript об’єкт, а обгортка над C++ кодом, яка забезпечує доступ до змінних середовища на системному рівні.

Тому кешуйте доступ до process.env через проміжну змінну, а не звертайтесь до нього при кожному запиті до вашого API.

У цьому допоможуть:
- NestJS: Cache environment variables
- ESLint-правило n/no-process-env

Учорашнє відео містить одну з ключових думок про те, що нам потрібно вміти створювати код з різною швидкістю/якістю.
Це вміння змінювати швидкість під завдання важливе в усіх сферах життя… Тут я зупинюся, бо починаю цитувати: "Thinking, Fast and Slow” by Daniel Kahneman.

За останній рік завдяки AI-інструментам я навчився краще управляти швидкістю вивчення нових інструментів/бібліотек.

Ось що дозволяє рухатися так, як я звик та як воно було до AI:
1️⃣ Learning by doing
2️⃣ Reading standart documentation
3️⃣ Video about the tool from courses/conferences

Ось що дозволяє рухатися deep&slow:
1️⃣ Several Deep research in your LLM: Best practices, alternatives, known <tool> problems and best practises to resolve them
2️⃣ The tool source code review. AI helps with navigation, explanation, etc
3️⃣ Best practise creation about this tool. Part of my consulting, so i review this with other experts.

Ось що дозволяє рухатися швидко:
1️⃣ Prompt for your LLM: There is documentation … Split it in 5 bitesize lessons with quize at the end. Start with the first lesson and based on quize explaine me what i missed.
2️⃣ GitDiagram. Example https://gitdiagram.com/nestjs/nest
3️⃣ DeepWiki. Example https://deepwiki.com/nestjs/nest

а які інструменти ви використовуєте для навчання? Які курси відвідуєте?

👀 https://youtu.be/rZSydNEcrR4

Учора вийшло оновлення на NotebookLM, яке дозволяє робити аудіо-огляди багатьма мовами, в тому числі й українською.

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

Я прикріпив згенерований подкаст на основі відео Бабича. Це звучить чудово!

А всього два місяці тому я тестував створення аудіо українською мовою та на ринку не було нічого якостного. За два місяці ми маємо українську у OpenAI та Google.

Обіцяний відео-розбір на каналі вже завтра.

Минулого тижня вийшли результати State of Web Dev AI.

Якщо ви не проходили це опитування, то там було чудове розділення:
- AI-powered text editors & IDEs: Cursor / Zed / Windsurf
- Coding Assistants: GitHub Copilot / JetBrains AI
- Code Generation tools: v0 / bolt / lovable

Деякі результати:
- Улюблені моделі — ChatGPT та Claude
- Найбільший біль по моделях — Галюцинації
- Найбільший біль по AI-powered IDEs — Обмеження контексту та пам’яті
- Найбільший біль по Coding Assistants — Галюцинації
- Найбільший біль по Code Generation tools — Низька якість згенерованого коду
- Найпопулярніші мови для генерації коду — JS та TS
- Більшість погоджується, що AI tools справді зробили їх продуктивнішими

Рекомендую почитати самостійно. Особливо зверніть увагу на розділ Resources (How developers are learning about AI).

Бабич записав відео як він спробував вайбкодинг.
Сергій, як завжди, харизматичний, але його постановка експериментів — це якась “срака-матика”.

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

Звісно я ділитимуся не лише власним досвідом, а й посилатимуся на вже накопичений досвід як індустрії загалом, так і на людей, які, на відміну від мене чи Сергія, мають вагу на міжнародній арені.

Тож, чекайте відео на моєму каналі вже найближчими днями.

Цього тижня я займався рефакторингом Fastify-застосунку.
Fastify дає максимальний контроль: жодної “магії” – усе будуєш власноруч. Саме тому кожна команда створює застосунок на основі своїх принципів (конвенцій). Найчастіше ці принципи ніде не задокументовані, через що кодова база дуже швидко стає неузгодженою.

До середини тижня я розібрався у більшості локальних конвенцій і зрозумів їхні причини, після чого зафіксував їх у документації - і робота пішла значно легше. Якщо додати ще рецепти для типових задач, це вже буде виглядати як документація до внутрішнього фреймворка. На щастя, робити це мені не доведеться: завдання вирішене. Наступного тижня я повертаюся до улюблених Nest.js декораторів і Terraform.

Але тепер я точно знаю: працюючи на проекті без фреймворка, де є лише набір інструментів (toolset), я обов’язково починатиму з фіксації conventions.

А як пройшов ваш тиждень?

Команда Node.js опублікувала в блозі звіт про Test CI Security Incident

The reported issue did not impact the Node.js runtime and there is no risk to users of Node.js

Тобто проблему вже вирішили, і команда розповідає деталі інциденту.

🔍 У чому була проблема?
У конфігурації CI/CD знайшли вразливість класу TOCTOU (Time-of-Check-Time-of-Use) — ситуація, коли перевірка коду відбувається до його фактичного виконання, і зловмисник встигає підмінити код між цими етапами. Нею скористались і заразили кілька серверів, на яких запускався CI/CD. Детальніше

⚖️ Цей інцидент добре ілюструє вічну дилему “Security vs. Developer Experience”.
Команда прямо заявляє:

“Існуючий дизайн CI-системи враховує можливість компрометації, визнаючи необхідність балансу між безпекою та зручністю для розробників.”

Тобто для Node.js team це не “або-або”, а постійний процес пошуку балансу. Тому що при занадто жорсткій безпеці розробники перестають контриб’ютити, а при занадто м’якій – виникає ризик компрометації інфраструктури.

✅ Висновок:
Цей кейс — приклад відповідального, прозорого підходу до безпеки в опенсорс-екосистемі. Node.js не створює ілюзію ідеального захисту, а замість цього будує стійку систему, де можливі загрози передбачені, контрольовані і публічно обговорюються. У продуктовій розробці також варто використовувати ті ж принципи.

🚀 Вийшов реліз Node.js v22.15.0
#nodejs_api

У цьому мінорному оновленні є два важливі моменти, на які варто звернути увагу.

1️⃣ Оновлення бази часових поясів: tzdata 2024b → 2025a
Деталі змін у реліз-нотах tzdata 2025a.
Якщо ваш застосунок має бізнес-логіку, що залежить від таймзон, це оновлення може стати breaking change. Щоб уникнути подібних ризиків у майбутньому, краще використовувати system-ICU, щоб оновлювати таймзони незалежно від оновлень Node.js.

2️⃣ Зʼявився новий метод process.execve() — системний виклик, який повністю замінює поточний процес на новий, зберігаючи той самий PID. Приклад:
console.log('Before execve pid:', process.pid);
try {
process.execve('/bin/sh', ['sh', '-c', 'echo After execve pid: $$']);
} catch (err) {
console.error('execve failed:', err);
}
Що це означає для Node.js розробників?
🐳 Мінімалістичний init-процес на JS у Docker-контейнерах: наприклад, можна спочатку отримати секрети з AWS Secrets Manager, а потім запускати основну програму, як треба по 12 Factor.
🔁 Hot-reload без втрати PID: перезапуск застосунку без його зупинки — актуально для IoT-пристроїв або embedded-систем.
⚠️ Новий вектор атак: тепер можливе підміщення логіки без зміни PID, що вимагає додаткової уваги до безпеки.