Node.js Recipes

Сьогодні ділюся спостереженням, яке часто зустрічається в проектах, де я проводжу Architecture Board Review.

Багато команд використовують лише одну базу даних, зазвичай PostgreSQL. Хоча це зручно і забезпечує консистентність, ми все одно використовуємо інші сховища даних (наприклад, S3) та інтегруємося з 3rd parties, як-от Stripe чи Firebase Auth. Через це питання узгодженості між DB та 3rd parties все одно доводиться вирішувати.

Не бійтеся додавати ще одну базу даних до проєкту - це може спростити розробку та архітектуру застосунку. Ось кілька прикладів:
1) SQLite для даних, що рідко змінюються. У додатку його монтують як Docker Volume з доступом лише для читання, а зміни здійснюються через адмінку, яка використовує той же volume з правами на запис.
2) Окрема база для аналітики. Наприклад, додатковий PostgreSQL або спеціалізована база для аналітичних даних, щоб основна база не була перевантажувана і це не впливало на користувацький досвід.
3) Realtime база. Firestore або Supabase можуть бути використані для реалізації повідомлень у реальному часі. Підключення серверних подій або веб-сокетів часто вимагає великих змін в архітектурі, тому окрема база для realtime notifications може бути зручною альтернативою.
4) Redis для кешування. Використання Redis або його аналогів допомагає зменшити навантаження на бази даних, пришвидшити доступ до часто використовуваних даних та забезпечити кращу масштабованість проєкту.

На завершення нагадаю про PostgreSQL Extensions. У певних ситуаціях це правильний інструмент для вирішення чергового інженерного завдання.

Розіслав електронні листи учасникам AI-Enabled Developer Experience. Перевірте свою пошту.

Один із моїх менті (світчер) поставив цікаве питання:

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

Питання справді чудове, тож поділюся своєю відповіддю публічно.

Я почав працювати напряму з США у 2016 році. Спочатку було незвично: у свої 30 років я був наймолодшим на дзвінках. Тоді на DOU жартували, що після 30 програмістів «спускають по Дніпру». А тут середній вік команди був близько 40.

Мене теж хвилювало питання: що я робитиму в 40, 50, 60 років?

Зараз мені 40, і я вже давно не переймаюся віком. Мабуть, допоміг приклад Джона, з яким ми працювали у 2021 році. У 70 років йому набридло бути менеджером, але й на пенсію він не захотів. Тож він вивчив React і зайнявся фронтендом. Його життєвий досвід поєднувався з технічною “незашореністю”, тому працювати з ним було справжнім задоволенням.

Окремо хочу зупинитися на технічній незашореності. На співбесідах я завжди кажу щось на зразок:

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.

Цю фразу з not married я якраз запозичив у Джона. А же досвід роботи з ним став для мене чудовим щепленням від ейджизму.

У березні я проводитиму внутрішній курс AI-Enabled Developer Experience для однієї компанії. Перед запуском мені потрібно зробити тестовий прогін контенту і перевірити, наскільки матеріали корисні та практичні.
Якщо цікаво взяти участь у пілотній групі, заповни форму: https://forms.gle/FQiudHwi28DwbeB5A
Участь безкоштовна. Відбір учасників буде на основі відповідей у формі (потрібна різноманітність)
Формат – самостійне проходження матеріалів + зворотний зв’язок.
Головна мета – перевірити, як AI може реально покращити Developer Experience у повсякденній роботі.

Update Feb 4. Закрив форму. Дякую всім, хто виявив інтерес. В кінці тижня ви отримаєте емейл.

Вчора мені виповнилося 40. Ось що я хотів би знати як професіонал, коли мені було 30:

1. Неможливо робити все одночасно швидко, якісно та правильно. Найчастіше це недосяжно; важливо вміти перемикатися між цими режимами.
Див. Make It Work, Make It Right, Make It Fast.
2. Оцінка результативності одного інженера (у тому числі вашої власної) не має сенсу. Важлива загальна ефективність команди.
Див. Групова динаміка.
3. Акції, опціони та криптотокени як частина винагороди мають сенс лише у компаніях, що вже вийшли на біржу. В іншому випадку шансів більше виграти в казино. Див. статистику стартапів, де співробітники змогли зробити exit.
4. Ми обираємо не один інструмент або фреймворк, а цілу екосистему та спільноту. Наприклад, екосистему Node.js або продукти Apple.
5. Одного разу вас звільнять, або ви самі підете. Див. 45 татуювань менеджера.
6. Найкращі пропозиції роботи приходять через нетворкінг. Тому не будь мудаком та не працюйте із мудакамі. Див. The Schmuck in My Office.
7. Перш ніж вирішувати проблему, переконайтеся, що вона справді існує для того, хто приймає рішення. Див. базові техніки продажів.
8. Люди не змінюються, але процеси можна й потрібно змінювати. Саме тому я почав робити DevOps.
9. Час важливіший за гроші, тому витрачай час і гроші на те, що заощаджуватиме час. Дивись, Time to the Market.
10. Дуже корисно писати нотатки "today i learned". До речі, цей канал почався саме так.

Інформації про зарплату це важливо. В українському IT ми дивимося DOU. В них як раз зараз триває зарплатне опитування.
Для світових зарплат я використовую glassdoor.com та www.levels.fyi. Наприклад, OpenAI найняв FullStack на $1.24M/year
Цікаво, який топ буде в аналітике DOU? Тому заповніть анкету

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. Які в тебе є питання за підсумками сьогоднішнього інтерв'ю?

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