На минулому тижні було випущено дві мажорні оновлення пакетів, які використовуються всіма: Prettier 3.0 та typescript-eslint 6.0. На початку цього тижня ком'юніті оновило залежні пакети (наприклад, eslint-plugin-prettier). Тому можна оновлюватись!

Офіційні анонси
👉 Prettier 3.0
👉 typescript-eslint 6.0

У typescript-eslint відбулися зміни в назвах конфігурацій та їх вмісті. Як на мене стало зрозуміліше та зручніше.

Основні нововведення Prettier:
👉 підтримка .prettierrc.js та його еквівалентів. Тепер можна легко використовувати extends, що раніше було неможливо.
👉 тепер prettier за замовчуванням ігнорує файли, які ігноруються .gitignore.
👉 виправлення в парсерах для CSS/GraphQL, щоб відповідати синтаксису.

Нагадаю, що eslint та prettier мають автофікс, який гарантовано робить безпечні оновлення у вашому коді. Бажаю приємного оновлення вашого проекту!

У березні 2019 року я мав можливість виступити на конференції JavaScript fwdays'19. Під час цієї події, разом з Тимуром Шемседіновим, ми мали честь відповідати на запитання учасників.

Під час одного з питань, до нас звернувся інженер з запитанням про обробку скасування запиту в середовищі Node.js. Хоча я не можу точно пригадати, яку саме відповідь подав Тимур, можливо, він згадав про AbortController, який на той час ще не був широко відомий і ще обговорювався в рамках TC39. Однак, я пам'ятаю свою власну відповідь, яка була короткою і некоректною – "кулі з фронту вже вилетіли, тобто їх не скасувати".

Зараз вже минуло 4 роки з того часу. В даний момент я займаюся консультуванням одного мобільного проекту. За останні півроку ми значно знизили кількість помилок як на стороні клієнта, так і на стороні сервера. Проте, у зв'язку з цим зросла частка помилок, які залишаються невідомими або непередбачуваними, з 0.01% до 2%. Цього тижня мені довелося зіткнутися з дивним явищем. Виявилося, що фреймворк Nest.js не генерує помилку, коли сокет вже закритий. Це стосується також інших фреймворків, таких як Express.js, Fastify або навіть простий Node.js, бо саме Node.js не генерує винятків, коли клієнт відключається до отримання відповіді від сервера.

З одного боку не можна писати відповідь у закритий сокет без помилок, але... Бажаєте перевірити? Натисніть cancel у Postman:

const { scheduler } = require('node:timers/promises');
const express = require('express')
const app = express()
app.get('/', async function (req, res) {
await scheduler.wait(60_000)
 res.send('hello world')
})
app.listen(3000)

Щобі ви розуміли рівень мого когнетивного дисонансу, у мене відчуття, що все що я знав до цього про розробку немає сенсу. Тому що Go/Python/PHP/etc поводяться так само. Але їх я ще перевіряю, бо Node.js я вже перевірив тричі.

Друзі, зустрічайте запис воркшопу «Infrastructure for Firebase project» від Нікіти Галкіна, який пройшов в рамках онлайн-конференції DevOps fwdays’23, 21 березня 2023 року 🤩

🎥 Опис воркшопу: Під час воркшопу ми налаштуємо реальний веб-проєкт, використовуючи Firebase фічі: хостинг, автентифікація, firestore. Нікіта пояснить, навіщо та коли використовувати ці функції, та продемонструє специфічні для Firebase практики DevOps. Набір інструментів включає firebase cli, firebase емулятори, terraform і Google Cloud Console.

Мова воркшопу – англійська

Приємного перегляду та не забудьте підписатись на наш YouTube-канал, щоб бути в курсі подій 🤗

Відео за посиланням ➡️ https://youtu.be/b0uVKeKxeX8

У мене багато подій, які не залишають часу на рецепти для каналу. Однією з цих подій слід поділитися публічно. Я прийняв запрошення від @fwdays приєднатися до програмного комітету конференції Node.js fwdays'23, яка відбудеться онлайн у грудні.

Розповім декілька слів про програмний комітет у FWdays. Його основне завдання – формування збалансованої та якісною програми. Участь у ПК відбувається на волонтерських засадах. ПК складається з 4-5 експертів, які зустрічаються онлайн раз на тиждень, щоб обговорити подані доповіді. Запрошенням експертів у ПК займається Міла, з якою знайомий кожен, хто подавав доповідь на FWdays.

Уточнивши у Міли ці деталі, я заглянув на сайт FWdays. На жовтень запланована конференція React+TS. Я вписався до ПК і цієї конференції, адже там є TypeScript.

На завершення скажу, що ця новина означає для каналу. Я повертаю рубрику #worth_seeing з відео, які я рекомендую переглянути.

​​AI and Web Development: Hype or Reality
#worth_seeing
Сьогоднішнє відео з конференції JSNation, яка відбулась на початку цього літа. Доповідач Wes Bos, створювач Syntax Podcast та курсів з веб-розробки. У цьому 20-хвилинному відео він демонструє декілька випадків, як штучний інтелект може прискорити процес веб-розробки. На завершення Wes робить висновки, з якими варто ознайомитись. І його останній слайд можна використовувати як принт на футболку:
We're Problem Solvers
Our tools are changing.
Don't ignore it. Stay sharp.

Ось посилання на тему відео:
👀 Відео з JSNation
👀 Відео з Coding Garden
🔗 wesbos.com
🔗 GitHub Next

Яким чином налаштовувати конфігурацію додатків у Node.js?

Дванадцятифакторний маніфест стверджує, що для належної конфігурації веб-застосунків необхідно використовувати змінні середовища. У Node.js для локальної розробки прийнято використання пакету dotenv. Його завдання полягає в зчитуванні файлу .env та встановленні значень в process.env. У середовищах, відмінних від локального, цей пакет не є необхідним, оскільки існують сучасні підходи для розгортання Node.js не викорістовують .env.

Добрим тоном є перевірка змінних середовища при запуску. Для цього довгий час я використовував dotenv-safe, який є обгорткою навколо dotenv. Додатковою його функцією є перевірка того, що всі змінні з .env.example визначені. Цього було достатньо для моїх проєктів. Тому мені не здається доцільним перевіряти, наприклад, чи є DB_PORT цілим числом або чи є DB_URL дійсним рядком підключення, як це пропонує документація @nestjs/config. Config - це сінглтон, який ви не будете мокувати у тестах.

Але повернемося до dotenv-safe. Його не оновлювали протягом 4 років. Тому замість нього я використовую такий код у config.ts:
import { readFileSync } from 'node:fs';
import { join } from 'node:path';

import { config, parse } from 'dotenv';

config({ path: join(__dirname, '..', '.env') });
const missedEnvironmentVariables = Object.keys(parse(readFileSync(join(__dirname, '..', '.env.example')))).filter((exampleKey) => !process.env[exampleKey]);
if (missedEnvironmentVariables.length > 0) throw new Error(`${missedEnvironmentVariables.join(', ')} not configured`);

Уважний читач помітить у цьому коді виклик readFileSync, що не рекомендується використовувати. А розуміючий побачить цей виклик readFileSync двічі.

Але незабаром цей типовий код у моїх проєктах зміниться. Справа в тому, що у версії 20 Node.js можна буде припинити використовувати dotenv. Зараз активно обговорюється add built-in .env file support. Це є з коробки в Deno/Bun та скоро буде в Node.js. Докладний розгляд цієї фічі я зроблю, коли вона піде в реліз.

19 вересня в рамках події Software Architecture fwdays я буду робити доповідь на тему "Exploring MACH Principles". MACH - це скорочення: Microservice, API-First, Cloud Native, Headless. У стартапах я використовую архітектуру, побудовану саме на цих принципах.

Цільова аудиторія конференції – Senior/Lead/Architect, тому під час підготовки доповіді я планую прочитати друге видання книги про мікросервісам. Ту саму, з бджолами на обкладинці, яку написав Сем Ньюман. Бо він теж буде виступати!

Якщо ви ще не читали цю книгу, то рекомендую це зробити. У моїй доповіді я не буду розповідати її зміст. Скоріше, я зосереджуся на microserivce mind set, який дозволяє краще організовувати код та швидше впроваджувати нові можливості...

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

Поділюсь діалогом, який відбувся в рамках мого консалтингу. Він ілюструє, як з рівня коду дискусія переходить на архітектурний рівень, а потім на її реалізацію на інфраструктурному. У результаті питання по коду просто відпадають.

➡️➡️➡️
привіт. https://xn--r1a.website/node_recipes/330. 2 пункт по фільтрам. Я правильно розумію, що ти пропонуєш сплітити такий сервіс на мікросервіси? Я бачу тут 3 варіанти для hybrid apps:
1) Хендлити в фільтрах по транспортам з контексту - if else
2) Ділити транспорти по мікросервісам. Але експірієнс такий собі. Можливо, в монорепозиторії таке виглядає набагато краще.
3) Бутстрапити два різних NestJsApplication в 1 процесі, у кожного додатка свій набір фільтрів. Ти пробував такий варіант?
⬅️⬅️⬅️
я пробував усі варіанти. розкажи мені яку проблему ти хочеш вирішити hybrid apps
➡️➡️➡️
Мікросервісна архітектура. Мікросервіс відповідає за свій власний домен. Скажімо це billing. На ньому лежить відповідальність ловити вебхуки по HTTP транспорту. Але у інших сервісів може з'явитися потреба запитувати інформацію по підписках, платежах користувачів. Це ось такий приклад в вакуумі. Інші мікросервіси спілкуються через NATS IO, у якого є request/reply, pub/sub, streaming. Виходячи з прикладу, один сервіс підтримує 2 транспорти (http, nats).
В ідеалі в сервісі знаходиться доменна логіка, з власними доменними помилками. При різних транспортах, доменна помилка може оброблятися по-різному. Для HttpException ми знаходимо їй статус, для RpcException http статус нам не потрібен, ми там можемо унікальний ідентифікатор їй видати.
І ось власне які підходи я виділяю:
1) Сплітити такий сервіс на 2 різних, у яких тільки свій транспорт - В результаті отримаємо так собі результат за власним досвідом. Якщо врахувати що для k8s probs потрібно http транспорт все одно сетапити для nats мікросервіса
2) Тримати транспорти в 1 сервісі, але тут почнеться ваханалія в інтерцепторах, фільтрах. Вручну додавати UseInterceptors, UseFilter - не дуже добре для експірієнса. Я цілююся все таки на глобальні фільтри, інтерцептори.
⬅️⬅️⬅️
Я б пішов по третьому шляху. Замість того, щоб в API Gateway виставляти всі мікросервіси яким необхідний реалізовувати webhook, я б зробив один такий мікросервіс. Його завдання слухати події (webhook-и) за межами вашої системи і відправляти їх всередину системи. Плюси такого рішення:
- Гарантованість доставки. Не всі зовнішні системи роблять retry як це робить страйп.
- Розділення прийому зовнішньої події і бізнес логіки по її обробці
- Можливість легко прикрутити Event sourcing саме для зовнішніх подій
Мінуси такого рішення
- Очевидно, не підійде, якщо у вас замість web-hooks використовується RPC over http для інтеграції з зовнішніми системами.
➡️➡️➡️
webhook-gateway який слухає всі вебхуки в системі, можна спробувати. Йому не потрібний буде жодний інший транспорт окрім як http. Потрібно буде запаритися над його high availability, RTO, RPO, якщо він буде включати в себе купу фічей системи.
Використовуючи nats jetsteam можна зробити 1 стрім, класти туди всі пейлоди хуків, а консьюмери вже будуть отримувати потрібні відфільтровані сабжекти.
Можна навіть не робити свій сервіс, а взяти API gateway + lambda
⬅️⬅️⬅️
ти правий. нагадую, що lamda/serverless container/k8s це спосіб розгортання вашого коду. спочатку необхідно на архітектурному рівні визначитися, а потім вже на інфраструктурному.

Змушений визнати, що мені не вдається робити відеоконтент у тому вигляді як я хочу. Настав час залишити спроби навчитися робити візуалізацію патернів коду, інфраструктури та архітектури у відео форматі. Це вимагає надто великої кількості зусиль, щоб зробити результат, який би мене влаштував. Мабуть, недаремно на ютубі є формат наукпоп (приклад https://www.youtube.com/@3blue1brown), але немає технопоп для пояснення в такому стилі інженерних концепцій.

У зв'язку з цим зараз опублікую пару опитувань.

Як, і, найголовніше, для чого розпарсювати JWT?

Я не переказуватиму застосування та структуру JWT. Це вже добре зроблено у https://jwt.io/introduction.

Власне питання в заголовку я використовую для перевірки як кандидатів, так і AI. Так минулого літа Copilot пропонував мені лише варіант із викликом методу decode бібліотеки jsonwebtoken. Проте вже наприкінці осені він покращився і зміг запропонувати ще й щось таке:
const payloadBase64 = token.split('.')[1];
if (!payloadBase64) ...
const decodedJson = Buffer.from(payloadBase64, 'base64').toString();
const parsed = JSON.parse(decodedJson) as Record<string, unknown>;

З того часу до часу Copilot додався ChatGPT/Bard/etc, але що вони всі не вміють належним чином записувати jwt.verify помилки у логи. Вони або виводить JWT повністю до логів, створюючи серйозну security уразливість, або взагалі не логують нічого. Що саме логувати залежить від проекту, але нагадаю критерій добрих логів - з них можна зрозуміти, що відбувається з вашим застосунком. Для цього потрібно розпарсувати JWT (до verify або невдачного verify). Тоді можна залогувати його header/payload, але не signature.

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

Як правильно вибрати тип установки пакета?

Звичайно має бути так. Ставте залежності правильно!

Зробив тестовий стрим. Не дивлячись на всю підготовку, звичайно, щось пішло не так. Поки що не зрозумів це проблема провайдера чи перегрів роутера.
Із запланованого контенту вийшло лише 15 хвилин. З ним можна ознайомитись, щоб зрозуміти формат. Поки що я його бачу як щотижневий стрим, присвячений продуктовій розробці із застосуванням Node.js. Демонстрації коду у відео немає, але це точно буде.
Дякую всім за підтримку. Наступний ефір буде наступної середи.

Новини Node.js розробки за минулий тиждень
#weekly_review

Node.js Security Releases – нові функції відсутні, виправлення безпеки не критичні, тому його можна пропустити.
Announcing TypeScript 5.2 RC – реліз спрямований на підтримку нових фіч EcmaScript: using та Decorator Metadata.
2023 State of the API Report – вийшов щорічний звіт про розробку API, Postman опитав 40000 розробників.
Is Jamstack Toast? – здається, термін вийшов у відставку, але сам підхід залишається актуальним для статичних сайтів.
Google introduced IDX, це web-IDE (Web Visual Studio), на основі Google Cloud Workstations з Codey AI.

​​Next Gen Package Management
#worth_seeing

Сьогоднішнє відео з конференції REFACTOR DX 2023, що відбулася минулого місяця в Торонто. Як можна здогадатися з назви, вона була присвячена досвіду розробника (Developer Experience). Дарсі Кларк виступив із захоплюючим keynote на заключення першого дня. Дарсі впродовж 4 років очолював інженерію npm. Наразі він працює над своїм стартапом, продовжуючи підтримувати проєкт Node.js та зусилля Фонду OpenJS Foundation у різних робочих групах. З таким багатим досвідом Дарсі дійсно має чим поділитися щодо JavaScript Package Management. Доповідь вийшла зрозумілою та насиченою інформацією, тому настійно рекомендую її переглянути.

Минуло два місяці, як я рекламував вам eslint-plugin-unicorn. Хочу це зробити ще раз. Якщо у вас його немає на проекті – встановіть його. Встановіть прямо зараз.

Приклади правил, які він додає:
– replaceAll замість replace
– заборона використання array.forEach
– імпортування вбудованих модулів тільки з node:

Повний список правил тут. У багатьох є автофікс, тому їх впровадження це питання кількох хвилин.

За допомогою Postman можна в пару кліків відтворювати запити з Chrome.