Хто такий HTTP/3?

Про HTTP/3 поки пишуть не так багато, тому є сенс коротко розібрати, які проблеми вирішує нова версія протоколу.

Найперше, що варто розуміти: HTTP/3 працює поверх QUIC/UDP, а не TCP, як HTTP/1.1 та HTTP/2.

QUIC підтримує незалежні потоки даних, кожен із яких має власний порядок доставки. Завдяки цьому HTTP/3 вирішує одну з типових проблем TCP — head-of-line blocking.

Наприклад, браузер одночасно завантажує зображення, CSS і JavaScript. Якщо загубився пакет із частиною зображення, браузер чекатиме повторної доставки даних лише цього потоку. Потоки з CSS і JavaScript зможуть продовжити роботу.

Можна подумати, що в HTTP/2 це працює так само, бо в статтях на Medium (від наших братів з Індії) пишуть про паралельне завантаження і потоки. Але не все так просто.

Усі HTTP/2-потоки передаються через одне TCP-з’єднання і якщо один TCP-пакет загубився, наступні отримані дані не будуть передані браузеру, доки втрачений пакет не надійде повторно.

Тому в HTTP/2 втрата одного пакета може тимчасово заблокувати всі логічні потоки, а в HTTP/3 — лише той потік, до якого належать втрачені дані.

З опису вище, можна прикинути де він буде корисний:

- Мобільні застосунки де потрібно враховувати поганий інтернет.
- Медіасервіси.
- Сайти з великою кількістю ресурсів.

Шо там в Node.js?

В нашому болоті активно працюють над підтримкою QUIC тому при бажанні можна погратись увімкнувши його - https://nodejs.org/api/cli.html#--experimental-quic

Transactional Outbox

Хочу розповісти про один з реально корисних патернів, який спрощує життя при роботі з legacy системами.

Сучасне legacy - це не завжди стара система. AI вніс свої поправки в розуміння legacy і тепер це може бути відносно новий продукт, який важко розвивати і мінорні зміни можуть призвести до каскадного падіння всієї системи.

Які є варіанти роботи з такими системами?

1️⃣ Переписати з нуля 😁😁

Найочевидніше, що може прийти в голову - знести все і зробити по нормальному.

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

2️⃣ Залишити як є і найняти більше розробників

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

3️⃣ Залишити legacy і паралельно створювати нову систему

Найбільш робочий варіант, суть якого полягає в тому щоб паралельно з legacy-системою розробляти нову систему, яка буде сумісна з поточною і поступово її замінить.
Тут багато підходів, патернів і набитих шишок, про які я буду писати в Telegram. Один з них - це Transactional Outbox.

Суть його в тому, щоб синхронізувати legacy і нову систему за допомогою подій, не ризикуючи втратити дані в момент їх передачі. Для цього буде використовуватися окрема таблиця (Outbox) де ми будемо зберігати інформацію про зміни в базі даних

Окрім цього, в нас буде окремий worker, який буде читати outbox таблицю і передавати події в брокер, який відправить їх в нову систему для синхронізації даних.

У спрощеному вигляді це працює так:

Legacy → таблиця Outbox → брокер → нова система.

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

Детальніше читай тут.

#microservices

Трохи забив сайт через брак часу 😐🚬

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

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

📎 - https://devs-hive.tech/interview-qa

Code Review Graph (CRG)🔥🔥🔥

Натрапив на цікавий інструмент для code review, який будує структурний граф кодової бази і дає доступ AI через MCP.

Можна сказати, що це такий собі Obsidian для code review де описуються звʼязки між файлами, функціями, класами і так далі.

Скоріше за все для стартапчиків буде overhead, але для legacy кріпто казіно - це може бути дуже крутим інструментом.

Детально описувати не буду, бо вони заморочились і створили дуже гарний і зрозумілий README де все гарно розписано - https://github.com/tirth8205/code-review-graph

Щось в цьому є 😂

Нове відео на каналі🍾

Детально розповів про одну з найбільш популярних сертифікацій по AI - AWS Certified AI Practitioner.

Розповів про те кому підходить ця сертифікація, основні теми і процес проходження

📎 - https://youtu.be/1nHIhpUBLto?si=r9Gw9R0Z1s1nzOP2

Ото в мене і підгоріло😅
Заходиш в інтернет, кожен пише про свій SaaS AI IPO Startup. Але що на практиці?

Всі ці Ілон Маски зосередились на туду лістах, фінансових апках, фітнес трекерах і тд. І ніхто не зробив простий Giveaway сервіс, щоб розіграти якісь речі👹

Так от, в мене є декілька хороших книжок, які я вже читав і хочу розіграти серед нашої спільноти.

Сьогодні, розіграємо Microservices patterns (Chris Richardson), на рос мові.

Умови
Все ізі, в коментарях під цим дописом напишіть microservices, ваш нік в тг. Наприклад microservices, @o_kazm
Ну і звісно треба бути підписаним на TG😁

Якщо ви в ЄС, то книгу отримаєте швидко, а якщо в Україні - доведеться почекати, так як укрпошта працює супер повільно (ну і я сподіваюсь, що на митниці її не завернуть).

Переможця визначимо 30.07.2026

Покращення там де ніхто не чекав🔥

В Node.js почали працювати над новим UI для документації і превʼю вже доступно - https://beta.docs.nodejs.org/

Як на мене виглядає красиво. Єдине, що в екосистемі JS ніхто особливо доку не читає тому я навіть не знаю для кого це😁

Це сталось, JavaScript нарешті навчився додавати числа😱😱😱

Отак подивишся і скоро вже не буде як пожартувати над JS з їхніми оновленнями

Детальніше тут