Новая часть цикла про V8 ждёт вас.

И в ней не только изучим теорию некоторых интересных оптимизаций, но и посмотрим на прикладные советы для нашего повседневного JS, которые помогут движку делать свою работу ещё лучше! 🙊

Погружение в v8. Часть 5. Скрытые оптимизации.

Финал цикла про V8!

Здесь рассмотрим, как движок взаимодействует с браузером, Node.js и WebAssembly, а также поговорим про будущее.

Погружение в v8. Часть 6. От среды к среде.

Этот цикл был для меня небольшим путешествием внутрь движка.
Надеюсь, читать его было так же интересно, как мне — писать ❤️

Интересная тема — как вообще организовывается авторизация в разных проектах.

У кого-то это JWT-токены (тут я когда-то писала про них), у кого-то — сессионные куки, у кого-то и то, и другое.
JWT удобен тем, что сервер выписывает токен, подписывает своим ключом, а клиент просто прикладывает его к каждому запросу. Но если токен утёк, то всё равно до конца его срока жизни он будет валиден — нет никакого механизма отзыва. Поэтому такие токены делают короткоживущими и добавляют второй — refresh-токен, чтобы обновлять сессию.
Дальше начинается самое интересное — где хранить этот refresh-токен. В localStorage небезопасно, в куках — только если httpOnly. А в чистом SPA это уже сложнее, потому что нельзя управлять такими куками с фронта.

Тут кто-то может начать задумываться про Backend-for-Frontend (BFF). Но, как по мне, делать BFF только ради авторизации — странное решение. Это может быть одним из пунктов, но не единственным. Если у вас есть ещё причины (например, хочется проксировать запросы, фильтровать данные или использовать SSR) — тогда да, BFF может дать больше гибкости и безопасности.
В целом, у SPA возможностей в плане авторизации гораздо меньше, чем у фронта с BFF. Поэтому если вы никак не можете менять логику авторизации на бэкенде — BFF может стать неплохим компромиссом.

И ещё важно помнить про блокировку пользователей и отзыв токенов. Даже если JWT живёт неделю, должна быть возможность ограничить доступ человеку, которого заблокировали. Иногда это решается централизованным чёрным списком токенов/сессий, иногда — проверкой статуса при каждом запросе.

Авторизация вообще тесно связана с безопасностью.
Бессмысленно ставить JWT и при этом не защититься от XSS, CSRF и не настроить CSP-политику. Это как поставить стальные ворота, но оставить рядом огромную дыру в стене — мощно, но бесполезно.

Ну и отдельный мир — это SSO (OAuth, OpenID, и вот это всё). Я с ним пока не работала, но тема явно интересная и заслуживает отдельного разбора.
А с чем сталкивались вы? Какие подходы к авторизации вам кажутся удачными, а какие — категорически нет?

Кстати, уже завтра я буду выступать на FrontendConf с докладом про нативные модули и node-gyp. Покажу разные интересные графики, и пообсуждаем целесообразность использования такого подхода в разработке на Node.js 💫

Вчера выступила с докладом про нативные модули (или native addons) в Node.js. Это расширения, написанные на C/C++, которые обеспечивают доступ к высокопроизводительным или низкоуровневым функциям, недоступным на чистом JavaScript.

По традиции, делюсь ссылкой на полезные материалы и приклыдываю свои слайды:
👉 Материалы на github
(в презентации много графиков с бенчмарками, а в материалах исходный код для них)

Если у вас есть вопросы по этой теме — пишите мне в личку @startpoint_forl, в сообщения этого канала или в комментарии под этим постом.
Также можете просто поставить реакцию, мне будет очень приятно)

А теперь — пост про то, что не влезло в доклад о нативных модулях: связь Node.js и C++, обработку исключений внутри модулей, команды для компиляции и работу с памятью.

Ещё немного про нативные модули в Node.js

Ну а я уже думаю над темами следующих интересных статей и докладов для вас. Будем копать глубже!)

В одной из частей цикла про V8 я рассказывала, почему важно сохранять массивы однородными и без «дыр» — тогда движок может их эффективнее оптимизировать.

В блоге V8 есть отличная статья, где показано, как можно посмотреть, какой тип элементов сейчас у массива и от чего он меняется. Ниже — краткий гайд, как повторить это у себя локально.

Нам понадобится отладочная (debug) сборка V8 — с ней можно смотреть не только на типы элементов, но и, например, как движок оптимизирует или деоптимизирует код.

1. Сначала ставим depot_tools, чтобы получить утилиту gclient.
2. Потом по инструкции из документации подтягиваем исходники V8.
На macOS важно: если у вас установлены только XCode Command Line Tools, их нужно удалить и поставить полноценный XCode. Подробности — здесь.
3. Дальше собираем движок:

gclient sync
cd /path/to/v8
git pull && gclient sync
tools/dev/gm.py arm64.debug  # debug-сборка для arm на macOS

У меня сборка шла очень долго, поэтому лучше сразу собирать правильную версию (release или debug). Debug-версия обладает бОльшими возможностями для логирования разной информации.

После сборки можно запустить движок в REPL-режиме:

v8/out/arm64.debug/d8 --allow-natives-syntax

Флаг --allow-natives-syntax позволяет использовать специальные отладочные функции, такие как %DebugPrint(array):

d8> const array = [1, 2, 3]; %DebugPrint(array);

Пример вывода:

DebugPrint: 0x2dcc00389c0d: [JSArray]
 - map: 0x2dcc0005b7d1 <Map[16](PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x2dcc0005b7f9 <JSArray[0]>
 - elements: 0x2dcc0006ca25 <FixedArray[3]> [PACKED_SMI_ELEMENTS (COW)]
 - length: 3
 - properties: 0x2dcc000007bd <FixedArray[0]>
.....

Можно и просто передать файл с кодом:

v8/out/arm64.debug/d8 --allow-natives-syntax ~/Documents/all-examples/v8/test.js

А если добавить флаг --trace-elements-transitions, то движок будет печатать все изменения типа:

// test2.js
const array = [1, 2, 3];
array[3] = 4.56;

v8/out/arm64.debug/d8 --trace-elements-transitions ~/Documents/all-examples/v8/test2.js 

Результат:

elements transition [PACKED_SMI_ELEMENTS -> PACKED_DOUBLE_ELEMENTS] in ~+15 at test2.js:1 for 0x2cf600389c45 <JSArray[3]> from 0x2cf60006ca0d <FixedArray[3]> to 0x2cf600389c55 <FixedDoubleArray[22]>

Дальше можно экспериментировать: добавлять в массив undefined, -0, пропущенные индексы — и смотреть, как V8 сразу меняет внутренний тип. Это наглядный способ понять, как движок анализирует наш код и почему иногда одно лишнее значение или неправильная инициализация может замедлить выполнение.