Привет!

Столкнулись с интересным кейсом, для меня это просто утечка памяти года - JSON.parse(undefined)

Этот простой код в Node.js до 18 версии вызывает небольшую утечку памяти, примерно 128 байт на вызов, которые не очищаются с помощью Garbage Collector.

Проблема описана в этом issue, и как будто бы исправлена в актуальных мажорках ноды, но фактически утечка присутствует в 14.x и 16.x версиях, по результатам наших проверок.

Почему утечка года:
- она маленькая и медленная, нужны хорошие нагрузки что бы была заметна
- совершенно неожиданная при профилировании (просто посмотрите на этот "undefined" на скриншоте, я просто игнорировал его когда встречал)
- очень легко воспроизвести, у нас оказалось несколько мест где парсим те cookies, которые часто undefined

Очень рад работать с такими крутыми коллегами, один из которых смог это раскопать)

Основной причиной, почему начали смотреть утечки памяти, оказался другой код, связанный с LRU кэшами, но в любом случае это хороший повод обновить Node.js

Согласен с Тимуром, пора уже везде при импорте встроенных библиотек писать неймспейс node: — так импорты зависимостей становятся нагляднее.

https://youtu.be/mRvzgBGLVyM

Туган як

В альма-матер бы пробраться, скучаю.

Люблю эту гифку за наглядность проблемы наследования. Не расширяйте сущности, особенно из внешних библиотек, если они явно не объявлены абстрактными. К сожалению, у нас в TS/JS нет финальных классов. Возможно совет стоит сократить до «Постарайтесь не использовать классы». В общем-то большинство классов, что я встречаю в JS/TS коде не инкапсулируют никаких данных. Даже более того, зачастую все методы этих классов можно объявить статическими и ничего не сломается.

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

Так зачем страдать, если можно просто оперировать функциями?

Отличный набор базовых советов по эксплуатации node.js в режиме SSR

Привет!

Давно хотел поделиться накопленным за последний год опытом оптимизаций и масштабирования SSR приложений.

Думал уложиться в несколько telegram постов, но меня немножечко прорвало, и получилась почти полноценная статья.

В статье расскажу про основные проблемы SSR (спойлер - React и Node.js) и рассмотрю ряд возможных оптимизаций:

- Static Site Generation
- Rendering at the Edge
- Микросервисы
- Оптимизациия кода
- Кэширование компонентов
- Кэширование запросов
- Rate Limiting
- Fallback кэш страниц
- Client-side rendering fallback
- Кластеризация и воркеры

Ссылка на статью в моем Notion - https://superoleg39.notion.site/SSR-04ad1ab46de346edb244a1112bd357a3

Очень жду ваш фидбек в комментарии)

Этим субботним вечером хочу напомнить вам простое правило, которое часто забывают.

Вот оно: пропсы не влияют на ре-рендер компонент в Реакте. Ре-рендер срабатывает при изменении стейта, это его триггер. А вот дальше, независимо от того, изменились ли пропсы или нет, обёрнуты ли объекты в useMemo или не обёрнуты — все потомки этого объекта будут перерисованы. Да, если потомки обёрнуты в React.memo то пропсы важны, вот здесь уже нужно ловить ссылки и заворачивать их в useMemo и useCallback. Но там ещё и из контекста может прилететь.

А помните, был такой Tink? Вот и я забыл.

История в том, что когда Yarn (который на самом деле Berry, а не оригинальный Yarn) выкатил Plug'n'Play, то NPM тут же презентовал Tink. Похожее решение, но в случае Tink это был не просто файл-маппер, не просто немного иной режим работы npm, фактически они хотели глубоко патчить резолвинг модулей в node.js. Но в целом решали ту же проблему — как вынести зависимости за пределы проекта и избежать их дублирования на диске. Да, pnpm решает ту же задачу, но иначе, на симлинках, что делает его более хрупким решением.

К сожалению, tink умер не родившись, после ухода zkat из команды npm. Но поругаться с yarn за первенство идеи, как я помню, они всё же успели 🙂

https://news.1rj.ru/str/artalog/624

Фан-факт про JS, который вы, возможно не знали. В спеке JS нет Integer, но есть абстрактная операция ToIntegerOrInfinity которая используется для приведения Number к целому числу. И работает она так, что просто отрезает всё, что находится за запятой — It converts argument to an integer representing its Number value with fractional part truncated, or to +∞ or -∞ when that Number value is infinite

Убедитесь сами, вот вам спецификация.

Вот ещё забавное — parseInt не рекомендуется использовать с Number, потому что он берёт строкое представление числа и режет его до точки или до e.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#using_parseint_on_non-strings

Бэкстейдж. Доклад, который вы может быть когда-нибудь увидите.

Никита успел раньше меня расписать

https://news.1rj.ru/str/mefody_dev/25

Дэн Абрамов написал на GitHub развёрнутый комментарий, к которому можно отправлять теперь всех, кто спрашивает «а что не так с Create React App»? Особенно порадовало, что тезисы в целом совпадают с моими, которые я недавно не публично озвучивал в ответ на очередной боллерплейт поверх CRA.

TL;DR
Основная проблема CRA в том, что он обеспечивает только клиентский рендер. Никаких префетчингов данных, никакого SSG и SSR в нём нет, как и нет умного разделения бандла на чанки с часто и редко обновляемыми кусочками. CRA создавался как инструмент для быстрого старта с zero-конфигурацией, но требования к современным приложениям иные.

"However, it doesn't meet the original goal of being the best way to create a React app anymore."

Даже если отбросить в сторону вопрос SSR/SSG (не всем нужно SEO, да и можно прикрутить костылик на папетире), у нас всё равно остаётся вопрос водопада сетевых запросов: скачали бандл, отрендерили компоненты, сфетчили данные, отрендерили следующий набор компонентов. Печалька.

Несколько раз Дэн подчёркивает, что реакт это библиотека, а не фреймворк (React itself is only a library). В нём нет высокоуровневых механизмов работы с данными (интересно, что иногда в ответах на проблемы от команды Реакта проскальзывает «возьмите хороший инструмент с кэшом»). В нём нет роутера, кэшей, серверной части и т.д. Он не диктует правила, он предоставляет инструменты.

Какой же видится выход? Создавать «эталонный» фреймворк у команды нет ни желания ни ресурсов. Выбирать один из имеющихся на рынке за эталон не хочется. Совсем депрекейтить CRA тоже не вариант — хочется всё же поставлять какой-то CLI из коробки. Да и нужно сохранить актуальность для кучи ранее созданных обучающих материалов.

В итоге Дэн предлагает рассмотреть вариант, что CRA превращается в лончер, который позволяет создать базовое приложение на любом популярном react-фреймворке: Next, Remix, Гэтсби или простенький шаблон на Vite.

И, конечно, интересно, что этот комментарий родился в ответ на предложение перевести документацию для новичков с CRA на Vite, потому что CRA безнадёжно отстал от прогресса. Давно пора!

Не так много разработчиков помнят, что вторым параметром в JSON.stringify передаётся функция-реплейсер, но, подозреваю, ещё меньше тех, кто знает, что вместо функции можно передать массив — белый список полей объекта для фильтрации (кому вообще это поведение понадобилось в API в таком виде?).

Там ещё и третий параметр есть, space, который может быть либо числом, либо строкой и от этого тоже зависит его поведение.

Вот такое ужасное API в спеке, в лучших традициях боевых апишек живых проектов.

На Секвойе вышла статья про Райана Дала. Текст конечно чистая беллетристика про трудное детство и героические преодоления, но есть любопытные моменты.

Совершенно близкое и понятное мне желание уничтожить ранние работы от стыда за них:

«Этим поступком Дал присоединился к ряду художников и изобретателей, таких как Уилла Кэтер, которая в предисловии к переизданию своего первого романа просила читателей рассматривать книгу как исторический артефакт ранних попыток, а не как отражение ее нынешних художественных достоинств. <...> Дал, не имея возможности кремировать свое цифровое творение, фактически просил всех присутствующих в зале и полмиллиона человек, которые будут смотреть его выступление онлайн, отнести Node к списку его "ранних работ".»

Импульсивность и радикальность поступков в молодости:

«В то время Дал был немного бескомпромиссным. У него была тенденция иногда очень агрессивно удалять некоторые вещи из Node. Одной из таких вещей были Promises. Дал счел их дизайн неэлегантным. "На следующий день было удалено огромное количество кода, - вспоминает Белдер, - и всем пришлось переписывать свои Node.js-программы, потому что теперь все работало по-другому".»

Дал сожалел, что подписал контракт с Joyent и отдал им Node.js, так как тех, в итоге, Нода интересовала только как маркетинговый инструмент и вкладывать большие деньги в развитие, нанимать больше инженеров они были не готовы. Позже это стало причиной выбора Далом иной модели развития для Deno, сейчас он получает венчурное финансирование от Секвойи и развививает свой продукт так, как он видит это сам, являясь полноценным владельцем, а не наёмным работником.

Ну и напоследок, самое важное (и я вижу ближашее будущее так же):

«Самым большим новшеством Deno является движение в сторону граничных вычислений (edge computing), которые Дал рассматривает как следующий большой сдвиг в веб-разработке. "В частности, бессерверные граничные вычисления (serverless at edge), то есть запуск сервера везде и сразу во всех регионах мира", - говорит он, - "вот где я вижу Deno через пять лет". Версия edge computing, которую Deno называет облаком изолятов (речь про V8-изоляты), запускает маленькие кусочки JavaScript в датацентрах по всему миру»


Почитайте, чтиво лёгкое и приятное.

Сегодня полдня спорили JS синхронный или асинхроннный. Так вот, совершенно не важно, как вы его называете, важно другое — понимание, как работает рантайм, в котором ваш JS запущен. Да, сам язык ECMAScript не обладает встроенными асинхронными апишками (ок, мне тут говорят про Атомики. Поговорим когда они будут везде!). Всё, что вы делаете в нём происходит синхронно. Максимум можно отбросить что-то в очередь микротасок — таким образом мы поменяем порядок обработки, но не освободим Event Loop. Цепочка из коллбеков вручную созданных промисов так и останется крутиться в фазе микротасков. Следующая итерация внешнего event loop не наступит. Из коробки мы не можем сказать «Эй VM, вот тебе корутина, выполни её в соседнем треде и верни результат по готовности». Нет у нас ничего для этого. Мы можем очень сильно упороться и написать свой Event Loop с прерываниями внутри JS — вот это мы можем да.

Таймеры, setImmidiate, функции, возвращающие промисы — всё это прилетает к нам из окружения. Именно платформа, где мы запускаем наш JS предоставляет работу с другими тредами и даёт нам EventLoop. В спецификации самого ECMAScript нет никаких таймеров и фечей — всё это внешние апишки. Есть отдельные ребята, попавшие в спеку — например, динамические импорты. Но их тоже крутит внешний рантайм, не сам движок JS.

Как работает код на node.js?

Мы выполняем небольшой синхронный код на старте и заряжаем задачи во внешние API. Например, задачу слушать какой-то порт. К это задаче мы привязываем коллбек. Дальше где-то во внешнем мире другой код, написанный на другом языке (на плюсах, например), в другом треде слушает порты. Между внешним миром и нашим JS-кодом крутится эвент луп. Он проверяет, не сработал ли триггер и вызывает соответствующий коллбек в JS. Коллбек снова синхронно выполняется (и может поставить новые задачи в планировщик). Коллбек это реакция на то, что во внешнем мире что-то произошло. Что случится, если коллбек выполняется слишком долго? Например, мы запустили очень большой цикл? Event loop будет стоять и ждать выполнения этой синхронной операции. Ничего не будет происходить. Никакие внешние запросы не будут обработаны, никакие таймеры не сработают. В нашем Event Loop возникнет лаг.

Для Node.js приложения это значит, что в этот момент конкретно этот экземпляр приложения будет тормозить для всех клиентов. Т.е. если у вас есть один медленный эндпоинт, то обращение к нему остановит обработку для всех остальных эндпоинтов. Из-за одного пользователя будут страдать все остальные. Именно потому долгие синхронные операции в Node.js максимально нежелательны. Если вы пишете консольный скрипт или стартуете приложение — вы можете делать что-то синхронно. Если же делаете обработчик запроса пользователя, то добро пожаловать в асинхронность.

Да, нам нужно превращать синхронные операции в асинхронные. Встроенных средств в языке для этого нет, но есть во внешней среде: таймеры и setImmidiate, например. Мы можем буквально сказать — выполни этот код в следующем цикле. Или, иначе говоря, «вызови коллбек когда внешний таймер сработает через 0ms (т.е. в следующем цикле)». Маленькие кусочки нашего синхронного кода будут вызываться по чуть-чуть и мы дадим Event loop время размотать накопившиеся очереди и вызвать другие коллбеки.

А как померить лаг? Мы же должны следить за ним. Ну, конечно, мы можем взять встроееный метод perf_hooks.monitorEventLoopDelay . Но давайте подумаем, как это можно сделать на коленке? Очень просто! Берём текущий таймстамп в высоком разрешении, вызываем setTimeout(fn, 0) и в его коллбеке снимаем таймстамп и измеряем разницу. Время, через которое сработает коллбек таймера с ожидаемо нулевой задержкой и есть наш EventLoop-лаг.

Итого, мы действительно пишем асинхронный код каждый день. И эту замечательную асинхронность нам даёт рантайм, котором наш JS запущен. Этот рантайм содержит и интерпретатор языка и EventLoop и работу с I/O. Потому Нода это не просто V8, это V8 + libuv. А Deno это V8 + ядро на Rust + Tokio.

С 15 марта откроется очередной набор в ШРИ. Естественно, записался туда читать лекцию по node.js

В этот раз на три страны, приходите. ШРИ штука не идеальная, но интересная и полезная. И бесплатная.

Upd

Вся история со ШРИ кажется мне очень уникальной (поправьте, если это не так). На чистом энтузиазме, бесплатно, одни ребята тратят личное время на обучение других. Учат как умеют, но но учат реальными боевыми знаниями. Другие ребята менторят и проверяют домашние работы. Многие преподаватели и менторы — сами бывшие выпускники (что и доказывает эффективность системы).

И вот этот корабль на невероятностной тяге успешно летит уже много лет.

Попробовал перетащить небольшой проектик с CRA (не я поднимал его на CRA, сами понимаете) на vite. Результат, ну как сказать. Да, vite поднимается быстро, и dev-режим на esbuild хорош. Но продакшен rollup оказался неожиданно капризным, посыпались пачками транзитивные зависимости с кривыми esm (например). Что-то удалось перебить альясами (что совсем не радует, конечно), что-то не удалось поправить никак без правок в самих зависимостях.

С next таких проблем нет.

Попросил ChatGPT нарисовать Мона Лизу на чистом CSS. Результат явно лучше, чем я справился бы сам.

Drawing the Mona Lisa using CSS alone would be quite a challenge as it is a complex piece of art with many intricate details. However, it is possible to create a simplified version using basic shapes and positioning techniques in CSS.

За годы работы я сталкивался со множеством моделей разработки. Таблички в экселе и «сделать вчера», ватерфолы, эджайлы: скрамы, канбаны и все их уродливые сочетания. И вот я думаю, что это всё вообще не имеет значения для эффективной разработки. Важна только команда, понимание общих целей и мотивация каждого отдельного участника процесса.

В моей сегодняшней команде нет стендапов. Даже текстовых. Нет ретро и грумингов. Вообще очень мало встреч. Мы встречаемся в начале и в конце недели и иногда в середине, для того чтобы синхронизироваться и обсуждать проблемы. В остальное время все работают спокойно и независимо. Неспокойно работает только дежурный, который меняется каждую неделю. Дежурный катит релизы и разгребает входящие баги, помогая второй линии поддержки.

Какие же ощущения у меня по таким процессам?

Во-первых (и в главных), это работает только в том случае, если команда состоит из людей, способных эффективно работать самостоятельно. Самостоятельно определять приоритеты и следить за своими целями. Под такие процессы нужно нанимать соответствующих людей, иначе не выйдет.

Во-вторых, спустя три месяца я всё ещё не понимаю кто чем именно занимается. В этом нет плохого для команды, но лично меня это расстраивает. Для меня важно видеть куда мы движемся вместе.

В-третьих, для меня утренний дейлик это хороший пинок продуктивности. Без него тяжеловато. Дни без встреч требуют большего самостоятельного контроля времени.

На днях мы провели первое планирование спринта. И я очень доволен. Не потому, что мне важны спринты и планирования. А только потому, что так происходит синхронизация целей и я начинаю видеть общую картину. Возможно, если бы мы сидели в одном офисе, то и это было бы не нужно, общая картина была бы вокруг меня весь день.

Не стройте процессы ради процессов, отталкивайтесь от реальных потребностей команды и бизнеса.

TIL На маке 80-й порт доступен без sudo 🤯