Node.js Recipes

Думки на вихідних: Full Stack LearningПодивився останнє відео Сергія Немчинського про фулстеків у 2026. Ринок в Україні змінюється: епоха «аутсорс продає двох вузьких спеціалістів замість одного» відходить, продуктових компаній стає більше, а аутсорс-проєктів — менше.У відео не вистачило ключового пояснення: чому фулстек реально цікавий бізнесу. Найскладніше в розробці — не код, а люди. Найбільше часу з’їдає комунікація навколо інтеграції: межі відповідальності, контракти, зміни, узгодження між командами. Фулстек тут цінний не як «два в одному», а як економія на комунікації та інтеграційних втратах.Сергій — підприємець: бачить тренд, збирає новий навчальний продукт і просуває його цим відео. Я про його курс Junior Full Stack. Вибір стеку React + Node.js виглядає правильним і стійким: тулінг змінюється, але ці технології ще надовго. Питання викликає система навчання. Підхід FoxmindEd: максимум практики, теорію студенти шукають самі, платформа дає задачі, ментор робить код-рев’ю. У 2021, коли я робив курс з Node.js для FoxmindEd, це працювало чудово: складно, боляче, ефективно — на виході виходили джуни, які були потрібні ринку. У 2021 ринку були потрібні джуни, які вміють писати код на правильному стеку. У 2026: інженер має думати, а AI пише код. Отже, ключова вимога до джуна — інженерне мислення. І навчання «через код-рев’ю» це мислення формує погано.Ось я й думав на вихідних, як реально передавати інженерне мислення від ментора до студента у 2026, зважаючи на вартість години часу ментора та купівельну спроможність студента. Але відповіді так і не знайшов.

Цього тижня для мене відбулася перша 🇺🇦 офлайн-конференція за останні 4 роки. Сьогодні повертаюся з Європи.Ось тезово, як пройшла WAWTech 2025.•⁠ ⁠Локація, де пахне ялиною, мандаринами та кавою•⁠ ⁠Гардероб, єдине місце, де не усміхаються і говорять лише польською•⁠ ⁠Стенди партнерів, де єдиний шанс на swag без черг лише о 8-й ранку•⁠ ⁠Main Stage, де на сцені ті, з ким ти маєш зробити селфі•⁠ ⁠Max Lounge, де немає черги за кавою, а в куточку хтось із доповідачів доробляє слайди•⁠ ⁠Growth Stage де на сцені про що завгодно, але не про те, навіщо прийшла аудиторія: “як зробити growth власної зарплати”•⁠ ⁠Speed dating zone, куди, як і на збір дронів, ти не потрапив, бо затримався у фотозоні на хвилину•⁠ ⁠Engineering Stage, де дуже цікаво, але нічого не зрозуміло•⁠ ⁠Кафетерій, також відомий як бермудський трикутник. Багато хто намагався там зустрітися, і лише одиниці знали, що їх два•⁠ ⁠Q&A-зона, де з поваги до одного поляка всі говоритимуть англійськоюAfter-party. У кожного вона була своя. На моїй були:•⁠ ⁠майстер-клас із паркування в центрі Варшави•⁠ ⁠повний розгром закусок мішленівського рівня від грузинської кухні•⁠ ⁠тест-драйв фотозйомки на розкладачку від Motorola (хочу таку від Apple)•⁠ загадка ⁠як коктейль із назвою Tomato rum може бути прозорим?Дякую що нагадали, чому конференції це не про доповіді, а про комунікацію та комьюніті

Цього тижня Linux Foundation оголосила про створення Agentic AI Foundation (AAIF).На мій погляд, AAIF стає третьою foundation, за якою варто стежити Node.js-розробникам, поряд із двома вже системоутворюючими організаціями:🏛️OpenJS FoundationВиступає куратором ключових open-source проєктів JavaScript-екосистеми, зокрема Node.js, Electron, jQuery, ESLint, Express та інших.🏛️ Cloud Native Computing Foundation (CNCF)Визначає розвиток cloud-native екосистеми, зокрема Kubernetes, Helm, Istio, Argo та пов’язаних інфраструктурних проєктів.До стартового набору проєктів AAIF увійшли:🤖 Model Context Protocol (MCP) від Anthropic🤖 AGENTS.md від OpenAI🪿 goose від BlockПерші два проєкти виглядають логічними та очікуваними — вони фактично формують базові контракти взаємодії між LLM-агентами, інструментами та кодом. Щодо goose, ситуація менш очевидна. Це open-source, local-first AI-agent framework для програмування, однак чому саме він був обраний як foundational-проєкт серед багатьох альтернатив — для мене поки відкрите питання. Я ще не мав практичного досвіду роботи з ним. Практичне знайомство планую зробити як буде час на завданнях Advent of AI Build with Agents.Дивує відсутність у переліку Agent2Agent (A2A) Protocol від Google, який фактично поглинув Agent Communication Protocol (ACP) від IBM/Linux Foundation. Цитата з сайту IBM:The information provided in this explainer about ACP may not reflect its current status, as ACP has merged with A2A under the Linux Foundation umbrella. З огляду на це, логічно було б очікувати A2A серед ключових проєктів AAIF, однак наразі його там немає.

📗📚📘Цікаві новина зі світу книжок:Що сталося?Юристи O’Reilly повідомили Amir Shevat автору Designing Bots, що компанія Anthropic використала його книжку для тренування AI-моделей і вже погодилася виплатити кілька тисяч доларів компенсації.Чому це важливо?Це формує прецедент оплати за використання авторського контенту, але водночас виглядає як “разове легальне піратство”: одноразова виплата — а цінність для моделі зберігається назавжди. Фактично маємо новий тип “видавничого контракту”, тільки без роялті й довгострокових прав автора.А до чого тут розробка?Код (включно з Open Source) масово використовується для тренування AI. Законність залежить від ліцензії.Шкода, що GitHub/GitLab не діють так само проактивно, як O’Reilly, бо самі тренують свої моделі на базі відкритого коду.Що робити нам?1️⃣ Розібратися з актуальними типами ліцензій та їхніми обмеженнями. 2️⃣ Додати в README свого open-source проєкту явну заборону чи дозвіл.ПрикладYou are prohibited from using this repository, its source code, documentation or artifacts to train AI models or datasets. Наостанок нагадаю, що у комерційних проєктах в package.json треба робити "license": "UNLICENSED"

На співбесідах я завжди кажу щось на зразок:I’m an expert in TypeScript, Node.js, AWS, but I’m not married to this tech stack and open to new approaches and tools. Учора ця фраза з мого intro викликала у рекрутера уточнювальне запитання:“Could you tell me more about this in detail?”Відверто кажучи, тут я трохи розгубився. У мене не було заздалегідь заготовленої відповіді на таке запитання. Але мене врятувала кмітливість. За кілька годин до цього я заповнював опитувальник Auth0 (той, що на скрині).Я просто сказав: “Let me share my screen”, відкрив опитувальник і пройшовся по пунктах, показавши, з якими інструментами працював і в яких проєктах. Фактично це був стислий переказ мого CV, але з tech stack focus.Мораль дуже проста:1) Ваше резюме, швидше за все, не читали детально.Його переглянули, але не аналізували. Тому підсвітити ключові моменти ще раз це ефективна стратегія.2) Коли не знаєш, як краще відповісти – покажи. Це економить час, знімає ризик непорозумінь і допомагає говорити по суті.

"Я уникаю Next.js через поганий DevExp" - розшифруйте будь ласка. Next.js — це закрита екосистема, яка обмежує вибір технологій і підходів. Ось чому:1️⃣ Деплой та залежність від VercelДля розгортання Next.js або потрібно використовувати Vercel, або вирішувати безліч додаткових завдань на власному хостингу.Команда Next.js свідомо блокує покращення DevExp для сторонніх платформ. Я це розумію: вони не хочуть створювати конкурентів своєму основному продукту.2️⃣ Складне усунення помилокДуже важко зрозуміти джерело проблеми: це Server Components, Turbopack, сам Next.js чи сторонній пакет.3️⃣ Надмір кількох неявних конвенційУ фреймворку багато прихованих правил (file-system conventions), які не перевіряються лінтерами або самим Next.js.Було б логічно, якби команда дозволила явно зазначати в конфігурації: «ми дотримуємося цієї конвенції», і отримувати помилки або попередження, якщо її порушено.4️⃣ Монолітність архітектуриПідхід “build APIs with Next.js” сприяє створенню монолітних застосунків замість модульної архітектури з окремими деплоями, як у монорепозиторіях.Що я використовую натомість:React Router v7 — дає більше контролю, прозорості й передбачуваності під час розробки.

Сьогодні хочу поділитися підходом до обробки помилок бази даних у Nest.js за допомогою Exception Filter.Ключові моменти:1. Перевірка бізнес-логіки на рівні БД – використання UNIQ/CHECK-обмежень у схемі бази даних.2. Робота з кодами помилок драйвера – наприклад, обробка стандартних кодів PostgreSQL (23505, 23514, 40001 тощо).3. Транзакції через typeorm-transactional – оскільки транзакції через @Transaction, фільтр є єдиним місцем, де можна перехопити помилку на рівні запиту.Приклад фільтра, щоб проілюструвати ідею:import type { ArgumentsHost, ExceptionFilter } from '@nestjs/common';import { Catch } from '@nestjs/common';import { Response } from 'express';import { DatabaseError } from 'pg';import { QueryFailedError } from 'typeorm';@Catch(QueryFailedError)export class TypeormExceptionFilter implements ExceptionFilter { catch(exception: QueryFailedError, host: ArgumentsHost) { const context = host.switchToHttp(); const response = context.getResponse<Response>(); if (exception.driverError instanceof DatabaseError) { if (exception.driverError.code === '40001') { return response.status(409).send({ message: 'Conflict. Please try again later.', }); } if (exception.driverError.code === '23505') { return response.status(400).send({ message: 'Should be unique', }); } if (exception.driverError.code === '23514') { switch (exception.driverError.constraint) { case 'not_negative_balance_check': { return response.status(400).send({ message: 'Not enough balance', }); } //… } } } throw exception; }} PS Цей метод не скасовує, а доповнює моніторинг журналу помилок вашої бази даних.

Існує команда docker scout quickview, яка аналізує Docker-образ і показує короткий звіт про вразливості, залежності та базовий образ.Вона корисна для швидкої оцінки безпеки контейнерів, особливо перед використанням образу у продакшн-середовищі.Втім, якщо цієї команди немає (бо треба docker login), можна обійтися без неї – достатньо відкрити сторінку потрібного образу на hub.docker.com і перейти у вкладку Tags, де також відображається кількість вразливостей для кожної версії.👉Приклад з Node.jsПід час воркшопів я використовую цю команду, щоб продемонструвати, чому варто обирати конкретну версію базового образу:✅ node:22.x.x-alpine3.21⚠️ а не просто node:22.x.x-alpine🚫 і тим більше не node:22.x.xРекомендую спробувати самому:docker scout quickview node:22docker scout quickview node:22-alpinedocker scout quickview node:22-alpine3.21 Порівняйте результати – різниця у кількості вразливостей будє суттєвою.👉РекомендаціяКоманда docker scout quickview — це must-have інструмент перед тим, як використовувати будь-який образ, особливо коли його рекомендує AI. Також, якщо ви відповідаєте за налаштування CI/CD, рекомендую додати це у ваш pipeline, подібно до npm audit.

Хочу показати вам різницю між продуктовими та платформенними інженерами.Учора в розсилці ADVENTURES IN NODELAND, яку веде Matteo Collina, вийшла чудова стаття — Noop Functions vs Optional Chaining: A Performance Deep Dive. У ній автор детально пояснює, чому Noop function працює швидше за Optional chaining.// Підхід 1: Noop functionfunction noop() {}function testNoop() { noop();}// Підхід 2: Optional chainingconst a = {}function testOptionalChaining() { a.b?.fn?.();} Не буду вам переказувати цю статтю – просто скажу, що вона чудово ілюструє, на чому зосереджені платформенні інженери. Для платформенних інженерів подібні оптимізації важливі, адже вони безпосередньо впливають на швидкодію фреймворків і бібліотек.Натомість продуктові інженери фокусуються на тому, що створює затримки в роботі продукту – зазвичай це мережеві виклики та база даних. Тому витрачати час, щоб виграти кілька наносекунд у коді, немає сенсу, якщо можна зменшити затримку на сотні мілісекунд, оптимізувавши business flow або покращивши індексацію бази даних.Платформенні інженери створюють технічні інструменти, а продуктові інженери використовують ці інструменти, щоб створювати цінність для кінцевого користувача. Обидві ролі важливі – просто вони розв’язують різні завдання, і підходи, які працюють у одній ролі, часто не підходять для іншої.

Self-code review – це практика, коли розробник самостійно аналізує свій код перед тим, як відправити його на зовнішній рев’ю або змерджити у main branch. Її мета – знайти помилки, підвищити якість, узгодженість і зрозумілість коду ще до командного перегляду. У 2025 році я вважаю використання AI для аналізу власного коду невід’ємною частиною процесу self-code review. Зазвичай я запускаю кілька циклів AI code review, перш ніж позначити pull request як готовий.Що я для цього використовував🤖 AI Self-Review (JetBrains)🤖 Codex (OpenAI)🤖 GitHub CopilotДля мене GitHub Copilot показав найвищу якість аналізу та швидкість роботи. Навіть без додаткової кастомізації (яку, утім, рекомендую налаштувати), Copilot ефективно підсвічує потенційні проблеми, пропонує релевантні фікси й адаптується до стилю коду. Його можна легко перезапускати кілька разів.👉 Рекомендація: тримайте Copilot увімкненим за замовчуванням для всіх pull request’ів – це забезпечує відчутний приріст якості ще до командного рев’ю.Деякі спостереження1️⃣ AI перевершує людину у виявленні очевидних помилок.Наприклад, сьогодні AI помітив, що я переплутав min і max у розрахунку high/low для свічкових графіків – банальна, але критична помилка, яку ШІ знаходить миттєво.2️⃣ AI поступається у забезпеченні єдиної стилістики та узгодженості коду на рівні всієї системи.Він не розуміє архітектурного контексту, внутрішніх домовленостей чи специфіки доменної логіки. Тут досвід і відчуття цілісності системи залишаються прерогативою людини.3️⃣ AI майже не здатен виявити пропущене у pull request. Нажаль людина теж.TL;DR; Human in the Loop – найкраща стратегія використання AI.