Команда 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 не створює ілюзію ідеального захисту, а замість цього будує стійку систему, де можливі загрози передбачені, контрольовані і публічно обговорюються. У продуктовій розробці також варто використовувати ті ж принципи.

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

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

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

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

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

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

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

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

Минулого тижня вийшли результати 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).

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

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

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

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

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

👀 https://youtu.be/rZSydNEcrR4

Учорашнє відео містить одну з ключових думок про те, що нам потрібно вміти створювати код з різною швидкістю/якістю.
Це вміння змінювати швидкість під завдання важливе в усіх сферах життя… Тут я зупинюся, бо починаю цитувати: "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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я пам’ятаю, що обіцяв зробити огляд 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

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

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

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

Більшість моїх записів присвячені моєму особистому досвіду, заснованому на роботі в стартапах. Проте я цікавлюся трендами, пов'язаними з 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 нас точно не замінить.

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

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

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

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

Як ефективно зменшити трафік у 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)