Node.js Recipes

Checklist: Error handling
Для повної відповіді на питання №5 краще підходить формат доповіді або навіть воркшопу. У текстовому форматі я зупинився на чеклісті. Кожен елемент списку представлений у форматі того, що має бути в проєкті, і питання, яке варто висвітлити під час інтерв’ю або задокументувати у вашому проєкті.

Рівень коду:
- Використовуються користувацькі класи помилок для різних типів виключень. Як і для чого їх використовують?
- Налаштований глобальний обробник(и) unhandled exceptions на вхідні запити. Приклади: Nest.js exception filters, Express error handler. Які задачі вирішує цей обробник?
- Налаштовані process.on('unhandledRejection') і process.on('uncaughtException'). Що вони роблять?
- Налаштований ESLint з правилами, що полегшують роботу з помилками. Які саме це правила?

Рівень застосунку:
- Є розділення Operational і Programmer Errors. Чим вони відрізняються?
- Налаштований retry для звернень до сервісів. Як саме він реалізований?
- Зміни в базі даних використовують транзакції. Як вони налаштовані?
- Реалізована стратегія “graceful shutdown” при критичних помилках або вимкненні. Що це таке і навіщо необхідно?
- Виконується валідація всіх вхідних даних. Як це реалізовано? Чому це необхідно?
- Визначена відповідальність за текст помилок для кінцевого користувача. Яка вона? Чи є інтернаціоналізація тексту помилок?

Рівень логування:
- Помилки в логах серіалізуються із збереженням stack-trace. Як це робиться? Що таке stack-trace?
- Помилки в логах серіалізуються із збереженням cause. Як це робиться? Що таке cause?
- Немає partial stacktrace. Чим це може бути викликано і як цього уникнути?
- Логи містять traceID для відстеження запитів. Як реалізовано його створення і логування?
- Інтегровані системи моніторингу та оповіщення про помилки. Які саме?

Nest.js має застарілий tsconfig
Рецепт є прикладом відповіді на 4 питання https://t.me/node_recipes/774
Команда nest new project-name генерує некоректний файл tsconfig, налаштований для застарілої версії Node.js (16-ї). Проблему посилює використання в екосистемі Nest.js пакета ts-node, який застосовується, наприклад, у проєктах типу typeorm або nest-commander. Пакет ts-node вже понад рік не оновлювався і досі не підтримує TypeScript 5.0 — Supporting Multiple Configuration Files in extends. Це обмежує можливість застосовувати рекомендовані налаштування з tsconfig/bases за допомогою:
{
"extends": ["@tsconfig/strictest/tsconfig", "@tsconfig/node22/tsconfig"]
}

Приклад ts-config, що відповідає сьогоднішнім best practise:
{
"extends": "@tsconfig/strictest/tsconfig",
"compilerOptions": {
// @todo extend from @tsconfig/node22/tsconfig after ts-node support extends array
// start of @tsconfig/node22/tsconfig
"lib": ["es2023"],
"module": "node16",
"target": "es2022",
"moduleResolution": "node16",
// end of @tsconfig/node22/tsconfig

"allowJs": false,
"checkJs": false,

"emitDecoratorMetadata": true,
"experimentalDecorators": true,

"forceConsistentCasingInFileNames": true,

"noEmit": true,
"baseUrl": "./",
"paths": {
"~/*": ["./src/*"]
}
},
"include": ["src/**/*", "tests/**/*"],
"ts-node": {
"require": ["tsconfig-paths/register"]
}
}

UPDATE:

а чому не module: "nodenext" і target: "esnext"?

Бо https://github.com/tsconfig/bases/blob/main/bases/node22.json#L8 яке йде з https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping

🚀 Node.js 22.11.0 тепер у LTS!

Node.js 22.x офіційно перейшов у Long Term Support (LTS)! Тепер ця версія перебуває у статусі “Active LTS” і буде підтримуватися до жовтня 2025 року. Після цього періоду вона перейде в режим “Maintenance” та залишиться актуальною до квітня 2027. Жодних змін порівняно з версією Node.js 22.10.0, окрім оновленяя метаданіх.

Docker hub вже має актуальні images, тому можна переходити.

WebStorm тепер безкоштовний для некомерційного використання!

JetBrains оголосила: тепер WebStorm доступний безкоштовно для навчання, open-source, хобі та створення контенту. Комерційні проєкти залишаються під платною ліцензією.
Це означає, що ви отримуєте повний функціонал IDE без обмежень! Єдина різниця — замість повної версії Code With Me, у безкоштовній ліцензії доступна лише його Community-версія.

Як отримати ліцензію?
1. Встановіть WebStorm і відкрийте.
2. Виберіть “Non-commercial use”.
3. Увійдіть у свій JetBrains-акаунт.
4. Погодьтеся з умовами.

💡Важливо: анонімну статистику збирають обов’язково, вимкнути її неможливо.

Сьогодні поширю мої загальні питання для технічних співбесід:

1. Ось package.json з нашого проєкту. Які в тебе виникають запитання щодо його вмісту? Прокоментуй залежності: з чим тобі подобається працювати, що б ти замінив і чому? З чим ще не стикався?
2. Покажи свій package.json з поточного проєкту (якщо це не порушує NDA) або pet-проєкту. Я оберу кілька пакетів і поставлю питання про них.
3. Уяви, що тепер ти інтерв'юєр. Як би ти перевіряв знання з теми ? Які б 3 питання ти поставив (просте, середнє, складне)? Можна вибрати одне з них та попросити кандидата відповісти.
4. Розкажи мені про недоліки в роботі з TypeScript, Nest.js, TypeORM, GitHub Actions, монорепозиторіями тощо. Це допомагає побачити глибину розуміння та досвід використання.
5. Уяви, що в продакшені виникла проблема, і застосунок почав працювати повільно. Як би ти діагностував і визначив причину? Це чудова можливість перевірити знання інфраструктури, моніторингу, логування та відповідних інструментів.
6. Як ти організовуєш обробку помилок у застосунку?
7. Що з останніх новинок у JavaScript-екосистемі ти вже випробував? Які твої враження?
8. Як ти працюєш з обмеженням API Rate Limiting? Перевіряє знання управління навантаженням, повторних спроб (retry) та масштабування застосунку.
9. Розгляньмо кейс: я — продакт-оунер і хочу, щоб ти реалізував фічу X. Які питання по вимогах ти б поставив і як би ти декомпозував їх у завдання для розробки?
10. Які в тебе є питання за підсумками сьогоднішнього інтерв'ю?

Використання такого формату запитань допомагає проводити співбесіду як розмову між двома колегами, а не як іспит.

Олексій у коментарях до посту про види боргу пропонує не використовувати цей термін:

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

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

Наприклад, з 5-го жовтня 2024 року 8-а версія eslint досягла end of life і більше не підтримується. Використання 8-ї або старшої є прикладом тех боргу, викликаного технічною інфляцією.

На завершення поділюсь планами на наступний стрим. Він буде як налаштувати eslint для Node.js проектів.

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

Один з підписників питає:

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

Відповім на це публічно та поділюся своєю невдачею. У мене саме так відбувається з навчанням Machine Learning. Щоб залишатися цікавим роботодавцям, треба вміти працювати з AI/ML. В чому саме проявляється це відчуття безкінечності для меня? За цей рік я вже двічі провалив сертифікацію Google Cloud Professional Machine Learning Engineer. Можна сказати щось типове: знання, здобуті під час підготовки, допомагають у роботі. Це не допомогає, бо провал все одно б’є по самооцінці та підсилює синдром самозванця.

Що я роблю в випадку невдачі? Те саме, що і в разі успіху. Спочатку відпочинок. Потім впорядковую нотатки та підводжу підсумки. Після цього — нова навчальна мета. Адже стару потрібно замінити, незалежно від того, чи була вона досягнута, чи провалена.

Keep learning, because in software development “it takes all the running you can do, to keep in the same place”

Node.js 23 is released!

Features:
- ESM Enabled by Default.
- Dropped Support for Windows 32-bit Systems: давно час було це зробити.
- --run command stable: конкуренція із npm/yarn за запуск скриптів?
- Test Runner Enhancements: корисно для авторів бібліотек, для тестування продакшен коду продовжуємо використовувати Jest.

Нагадаю, що версії з непарними номерами (наприклад, сьогоднішній Node.js 23) ідеально підходять для раннього тестування нових можливостей у вашому середовищі. Такі випуски не переводяться в LTS. А ось Node.js 22 стане LTS протягом тижня, що розпочнеться 29 жовтня. Тому заплануйте оновленя з 20 до 22.

Я здав AWS Certified AI Practitioner у серпні.
Для підготовки було достатньо матеріалу зі skillbuilder.aws

Цієї суботи відбудеться конференції React fwdays’24. 17087D5D3A на 15%.
Хочу їх підтримати та нагадаю, що з минулих конференцій від fwdays багато крутих відео. Тож давайте проведемо #like_and_share.

Мета гри - поділитися своїм досвідом та дізнатися про досвід інших учасників. Правила:
1. Публікація в каналі визначає тему. Сьогодні це відео з каналу https://www.youtube.com/@fwdays
2. У коментарях кожен може залишити посилання на відео, коротко його описати, та чому відео є корисним/цікавим.
Приклад: https://www.youtube.com/watch?v=R4sTvHXkToQ Класна харизма Соловйова зробила з цього відео мєм.
3. Учасники голосують, використовуючи лайки. Не ставте негативні лайки, бо вони також зараховуються як позитивні.
Відео зі мною, Нікітою Галкіним, йдуть поза конкурсом.
4. Цієї п'ятниці, о 21 по Києву підіб'ємо підсумки. Переможець отримає 12-місячну персональну підписку на будь-яку IDE від JetBrains.

Нагадаю вам, що тех борг має різні види. Виділяють:
1. Архітектурний борг — виникає через недостатнє опрацювання або зміни архітектури системи.
2. Кодовий борг — з’являється через погане або неефективне написання коду.
3. Тестовий борг — нестача тестів або неякісне покриття коду тестами.
4. Інфраструктурний борг — застаріла або неефективна інфраструктура проєкту.
5. Документаційний борг — нестача або відсутність документації по проєкту.
6. Процесний борг — неефективні процеси розробки або їх відсутність.
7. Борг безпеки — відсутність заходів безпеки або ігнорування вразливостей.
8. UI/UX-борг — погане опрацювання інтерфейсу користувача та взаємодії.
9. Борг залежностей — використання застарілих бібліотек та фреймворків.
10. Бізнес-борг — спрощення або пропуск функціоналу заради прискореного релізу.
11. Командний борг — виникає через затримку в наймі потрібних фахівців або найм некваліфікованих співробітників для заповнення вакансій.

Борги не варто затягувати, інакше настане технічна смерть проекту, коли дешевше переписати з 0, ніж підтримувати/розвивати поточний.

Як приклад, чому борги треба віддавати, поділюся своєю історією про здоров’я. Я не робив чек-ап з моменту виїзду з України, а це майже 3 роки. Метрики контролю здоров’я: логування ваги та Heart rate variability (HRV), який мені вимірює Whoop. Метрики не тішили, останній рік вага при зрості 192 см – 110 кг (референсне значення 85-93 кг), HRV 48 мс (референс 45-95). І це при більш-менш регулярних заняттях спортом. Місяць тому HRV впав до 25 мс. А до вечора другого дня піднялася температура, і тієї ж ночі мене прооперували – видалили запалений апендицит. Пройшов місяць, я не робив якихось суттєвих змін у дієті чи фізичних навантаженнях, але HRV виріс до 65 мс і продовжує зростати, а вага знизилася до 102 кг. Висновки робіть самі.

Deno 2.0

Позавчора вийшла нова мажорна версія Deno. Ключові нововведення:
- покращена сумісність з Node.js та npm;
- тепер Deno включає менеджер пакетів: додано команди deno install, deno add, deno remove. Є підтримка приватних npm-реєстрів;
- введено графік LTS (довгострокової підтримки).

Офіційний анонс as text, але краще as video. Бо Райан Даль та команда зробили презентацію на рівні Apple.

Сьогодні стартував Hacktoberfest 2024! Це щорічна подія на підтримку open-source, де розробники з усього світу роблять внесок у відкриті проекти на GitHub та GitLab. Потрібно зробити 4 pull request-и, щоб отримати бейдж учасника. Улюблених нами футболок не буде — економія маркетингових бюджетів. Але будуть кредити для Digital Ocean.

Ідеї для участі:
- Додати/покращити types для пакету, який ви використовуєте.
- Відкрити pull request зі змінами, які ви вносите за допомогою patch-package. У мене, наприклад, свого часу чекає TypeORM.
- Покращити документацію або код node.js.

Happy coding!

Нагадаю, 2 години на debug економлять вам 5 хвилин на читання документації

Навіщо вам може знадобитися class-validator-jsonschema?

Під час виконання типової задачі в 2024 API з AI для налаштування моделі необхідна JSON Schema. Приклад такої задачі — отримати дані потрібної структури з txt/pdf/image. З цим чудово справляються generative models. За допомогою JSON Schema визначається структура відповіді. Писати JSON Schema/Swagger/etc вручну — не найприємніше заняття. Ми хочемо писати код, а JSON Schema багатослівна і її незручно ділити на частини, тому її краще генерувати. Як представник NestJS-екосистеми для опису валідації даних я використовую class-validator. Його відмінно доповнює пакет class-validator-jsonschema.

Виходить чудовий DevEx з підтримкою типів. Необхідно визначити кілька класів, які ми очікуємо у відповідях від AI, додати в них декоратори для валідації та згенерувати схему для відправки в модель. Нагадаю, якщо в класах потрібні get/set, то результат треба проганяти через class-transformer.

Взагалі, тема кодогенерації дуже обширна. Огляд задач, принципів та інструментів, які її вирішують, я зроблю 19 жовтня на React+ fwdays’24. Доповідь буде в онлайн форматі. 17087D5D3A на 15%.