Node.js Recipes

На написання рецептів не вистачає часу. Але я радий з вами поділитися backstage з програми конференції.

За годину відбудеться ефір з Нікітою Галкіним та Віктором Турським. Хлопці розберуть новинки, представлені на Google Next 2023. До зустрічі в ефірі!

Починаємо!

Через 4 години наступний огляд новин щодо продуктової Node.js розробки. Підключайтеся подивитися та поставити запитання.

З Днем Незалежності🇺🇦 Node Recipes – Weekly Review буде за 40 хвилин 👀 https://www.youtube.com/watch?v=QCTf7WL_kyQ

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

Минуло два місяці, як я рекламував вам eslint-plugin-unicorn. Хочу це зробити ще раз. Якщо у вас його немає на проекті – встановіть його. Встановіть прямо зараз. Приклади правил, які він додає: – replaceAll замість replace – заборона використання array.forEach – імпортування вбудованих модулів тільки з node: Повний список правил тут. У багатьох є автофікс, тому їх впровадження це питання кількох хвилин.

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

Новини 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.

One more time https://youtube.com/live/JCsZXrWu88k?feature=share

Добрий вечір. Через 20 хвилин зроблю тестовий стрим. До зустрічі в ефірі 👉 https://www.youtube.com/watch?v=ai9LWmq3aDc

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

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

Як, і, найголовніше, для чого розпарсювати 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 – наприклад, невірний напрямок трафіку через некоректне середовище.

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

Поділюсь діалогом, який відбувся в рамках мого консалтингу. Він ілюструє, як з рівня коду дискусія переходить на архітектурний рівень, а потім на її реалізацію на інфраструктурному. У результаті питання по коду просто відпадають. ➡️➡️➡️ привіт. https://t.me/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 це спосіб розгортання вашого коду. спочатку необхідно на архітектурному рівні визначитися, а потім вже на інфраструктурному.

19 вересня в рамках події Software Architecture fwdays я буду робити доповідь на тему "Exploring MACH Principles". MACH - це скорочення: Microservice, API-First, Cloud Native, Headless. У стартапах я використовую архітектуру, побудовану саме на цих принципах. Цільова аудиторія конференції – Senior/Lead/Architect, тому під час підготовки доповіді я планую прочитати друге видання книги про мікросервісам. Ту саму, з бджолами на обкладинці, яку написав Сем Ньюман. Бо він теж буде виступати! Якщо ви ще не читали цю книгу, то рекомендую це зробити. У моїй доповіді я не буду розповідати її зміст. Скоріше, я зосереджуся на microserivce mind set, який дозволяє краще організовувати код та швидше впроваджувати нові можливості... Здається, я вже почав розповідати зміст доповіді, хоча цей пост мав бути анонсом.Лайкнути мою доповідь, переглянути інших доповідачів та зареєструватися можна тут.

#code_only