#004 — uWebSockets.js Security + React Performance Tracks

Stream #004

Дата: 5 червня 2026 | 19:00 London / 21:00 Kyiv
Формат: Дві доповіді · ~175 хвилин
Гість: Олександр Блажейко
YouTube: https://youtube.com/live/Pad_b_yQyt8

Учасники

Олег Левченко — Senior Full Stack JavaScript Developer (React / Node.js / AWS)
The AA · Cardiff, UK
YouTube @zloyleva · itfriday.community

Олександр Блажейко — Software Development Engineer · Fullstack, 7+ років досвіду
Україна
LinkedIn · itvibe.party

Будує itvibe.party — платформу що поєднує чат, синхронний AI-перекладач і персонального AI-вчителя. Другий стрім поспіль — цього разу іде глибше в безпечні патерни uWS.

Ключові тези

Доповідь 1 — uWebSockets.js Security · Олександр Блажейко

Один принцип на обидва транспорти: raw → snapshot → validate → context → handler
Аксіома uWS: req живе тільки до першого await — весь pipeline працює зі снепшотом (collectRequestMetadata), а не з оригінальним об'єктом
Cookie allowlist: COOKIE_NAME_PATTERN + COOKIE_VALUE_PATTERN — невалідні cookies тихо відкидаються без 400, зіпсована session-cookie робить запит анонімним
Header allowlist: захист від CR/LF injection (response splitting / request smuggling); cookie-заголовок навмисно виключений з headers Map
Rate-limit ДО body: синхронно, до res.onData() — якщо зробити await тут, uWS може доставити тіло до реєстрації обробника, і хендлер зависне назавжди
HTTP-конвеєр перевірок: rate-limit → query (flattenQuery + ArkType) → 415 / 413 → body validation → збірка HttpData → middleware (session/auth) → handler
WS-конвеєр: handshake token (Sec-WebSocket-Protocol) → Redis verify (двоступенево: ws-token TTL 120с + session) → per-message: envelope → session TTL → per-route payload
ArkType через єдиний Validator<T> інтерфейс: body, query, URL-params, WS-envelope, WS-payload — один engine
WsContext без session/auth за дизайном: auth — один раз на handshake, identity в userData; session передається аргументом але навмисно ігнорується (_session)
Object.freeze({...payload}) — immutable snapshot WS-payload у handler

Доповідь 2 — React Performance Tracks · Олег Левченко

React Conf 2025 анонсував Performance Tracks — власні треки React прямо у Chrome DevTools Performance panel
Під капотом — Chrome Performance Extension API (console.timeStamp або performance.measure з devtools metadata); будь-яка бібліотека може додати свої треки
Три групи треків: Scheduler (Blocking / Transition / Suspense / Idle), Components (flamegraph), Server (тільки dev + RSC)
Scheduler track: показує Update → Render → Commit → Remaining Effects; Blocking = синхронна робота від user interaction; Transition = фонова через startTransition()
Cascading updates видно як вкладені блоки — React відкидає вже виконану роботу і починає знову; dev build показує stack trace: ім'я компоненту + метод
Components track: flamegraph рендерів; Changed Props Inspection — клік на компонент показує які props змінились (відповідь на "чому рендерився?")
Server track: Promises у RSC + flamegraph Server Components; агрегація fetch-запитів з назвою функції замість сотень окремих спанів
Profiling build: react-dom/profiling замість react-dom/client — Scheduler + Components без Server track; набагато ближче до production performance
Увімкнути: DevTools → Performance → Settings → "Show custom tracks"
Старий React DevTools Profiler — для швидкого "хто зайвий рендериться"; Performance Tracks — для реальної діагностики лагів у контексті network/JS/layout

Таймкоди

Будуть додані після стріму.

#004 — uWebSockets.js Security + React Performance Tracks ​

Учасники ​

Ключові тези ​

Доповідь 1 — uWebSockets.js Security · Олександр Блажейко ​

Доповідь 2 — React Performance Tracks · Олег Левченко ​

Таймкоди ​