Дайджест за 2024-03-04 - 2024-03-08

Does your team need a meeting reset?
С приходом ковид многие компании перешли на удаленный формат работы. Из-за этого сильно повысилось количество встреч в календаре. В некоторых командах встреч стало так много, что уже некогда работать. Поэтому некоторые компании начали движение в обратную сторону. Например, есть инициатива no meetings day - нужно выбрать день, когда ни у кого не должно быть созвонов. В данной статье рассматривается практика reseting meetings.

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

⭐Reporting Core Web Vitals With The Performance API
Крутая статья про возможности Performance API в браузере. Автор подробно объясняет, как с современным API можно снимать метрики производительности страницы и как с ними работать. Я раньше думал, что есть перформанс метки и это, в общем-то, все API. Но в статье показываются крутые примеры как использовать PerformanceObserver, который позволяет узнать не только цифры конкретных метрик WebVitals, но и почему они такие.

Например, есть метрика Largest Contentful Paint. Можно не только узнать, какая у нас метрика LCP, но и вывести элемент, на основе которого считается метрика. Ниже пример кода из статьи.

⭐Справочник React
Большой справочник по React на русском языке. Описано много разного, начиная от перевода официальной документации React и заканчивая интеграциями с менеджерами состояния. В справочнике хорошие статьи и примеры кода, приятно читать.

Если вам понравился такой справочник, то у автора есть еще по популярным темам: HTML+CSS, Typescript, Angular, Solid, React Native, PWA, Node.js, Python3, XSLT, Базы данных.

Introducing AI SDK 3.0 with Generative UI support
Недавно Vercel запускали генератор React-компонентов с помощью LLM-моделей по запросу. Теперь же они показывают SDK, которая позволяет интегрироваться с LLM-моделями и показывать пользователю ответ в виде React-компонента.

У обычных чатов с LLM (например, у того же chatGPT), общение происходит в чате обычным текстом, что не всегда удобно. Vercel AI SDK позволяет дать более богатый пользовательский опыт, отображая не просто текст, а React-компоненты.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Why React Server Components Are Breaking Builds to Win Tomorrow

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

Рекомендую к прочтению, если вы еще не читали подобных статей и интересуетесь тем, как развивается React.

https://www.builder.io/blog/why-react-server-components

#development #javascript #react #reactServerComponents #recommended

Introducing JSR - the JavaScript Registry

Команда Deno сначала придумала свой рантайм для исполнения JS, а теперь представляют свой тулинг для реджистри с пакетами - JavaScript Registry (JSR). В основе JSR лежит идея, что тулинг для управления пакетами и реестр пакетами должен предоставлять лучший DX, чем текущие решения

NPM проделал большой путь в своем развитии, но сообщество проделало куда больший путь и хотелки разработчиков отличаются от того, что дает NPM. Например, до сих пор не решен вопрос, какой код нужно публиковать в npm - es5, es6 или может быть вообще не транспайлить код и поставлять исходники как есть?

Что же предлагает JSR. Я могу выделить 2 основных поинта

ES-модули вместо поддержки разных стандартов - сейчас, при публикации в npm, приходится думать над тем, в какой модульной системе публиковать пакет, или же поддерживать несколько систем сразу. Прогресс неумолимо наступает и ES-модули становятся все популярнее, но безопаснее поставлять одновременно точки входа для commonjs и es-модулей

DX как для автора, так и для пользователя - концепцию JSR можно описать так: "пусть разработчик пишет код как ему удобно, а JSR сделает так, чтобы пакет было удобно использовать". Что это значит? В JSR есть фичи для DX. Например, автор пакета просто пишет код на TypeScript, публикует его, а JSR сам его затранспайлит и поставит его готовым к интеграции в Node.js, Deno, Bun. Другая прикольная фича, это автодокументация. JSR сам собирает доку по интерфейсу, который предоставляет либа. Для этого достаточно хорошо описать типы и JSDoc к интерфейсам. Нельзя также не упомянуть, что все пакеты проверяются автоматикой и они получают оценку качества. Выглядит это почти 1 в 1 как отчет lighthouse: у вас 82 балла из 100 и список пройденных проверок и проблем.

Честно сказать, выглядит круто. Сообществу, ИМХО, не хватает хорошего тулинга для публикации пакетов. В статье более подробно описано, как начать пользоваться JSR и какие еще фишки там есть.

https://deno.com/blog/jsr_open_beta

#development #javascript #deno #registry #jsr

Introducing runes

В Svelte используется свой компилятор для обеспечения реактивности компонентов. Вы просто объявляете переменную и используете ее в шаблоне, а Svelte компилятор сам делает её реактивной. Иногда все не так просто, но не в этом суть. В Svelte5 уходят от этого подхода и теперь реактивность будет явной. Чтоб было не скучно, названо это рунами.

В статье объясняется разница между новым и старым способом написания кода, а также на что это повлияет. Я недавно писал браузерное расширение с применением svelte и в целом согласен с мотивацией, описанной в статье: магическая реактивность завораживает, но хочется более явного API для этого и возможности использовать его не только в svelte файлах.

Ниже приведу примеры кода, как делать реактивные переменные сейчас, и как их делать в рунах

Пример реактивных переменных в svelte без рун

<script>
// объявляем пропсы
export let width
export let height 

// расчитываем реактивный computed
$:  area width * height

// объявляем переменную. Svelte сам сделает её реактивной
let count = 0
// handler клика на 
function increment(){
  count++
}
</script>
<button on:click={counter.increment}> {count} </button>
<div> {area} </div>

Пример реактивных переменных в svelte с рунами

<script>
// объявляем пропсы
let { width, height } = $props();

// расчитываем реактивный computed
const area = $derived(width * height);

// объявляем переменную
let count = $state(0);
// handler клика на 
function increment(){
  count++
}
</script>
<button on:click={counter.increment}> {count} </button>
<div> {area} </div>

В целом, API стало более явным, но осталось удобным.

https://svelte.dev/blog/runes

#development #javascript #svelte

Puter: Internet OS and Desktop Environment in the Browser!

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

В демке можно позапускать vscode, терминал, paint, файловый менеджер, камеру и многое другое. Можно даже, как я понял, вставить свое приложение. Интересно, что сам Puter написан на чистом JS + JQuery (вот мы и нашли пользователей JQuery). Ребята решили не брать какой-то сложный фреймворк для того, чтобы приложение работало быстро.

Зачем и кому это нужно? В целом, юзкейс конечно нишевый, но, допустим, такие штуки могут быть полезны, чтобы собирать какие-то свои устройства и предоставлять пользователям привычный интерфейс. Купить какую-то дешевую железку, которая умеет запускать линукс и в нем браузер, подключить к ней мышку и клаву и залочить окно на Puter - и вот у вас управляемая удобная песочница с нужными вам приложениями, из которой сложно выйти. При этом, как я понял, можно описывать свои приложения для Puter на html+js+css, что позволяет делать что-то типа своих сетапов Puter.

https://github.com/HeyPuter/puter

#development #javascript #library

React Geiger

Библиотека для React, которая воспроизводит звук счетчика Гейгера на медленные рендеры React-компонентов. Т.е. вы подключаете её к себе на страницу и будете слышать пощелкивания каждый раз, когда случается рендер дольше определенного значения (50ms). На страничке проекта есть демо, где можно получить экспириенс, не устанавливая эту либу в свои проекты. Хотя я попробую на досуге подключить либку в рабочий проект.

https://github.com/kristiandupont/react-geiger

#development #javascript #react #performance

Дайджест за 2024-03-11 - 2024-03-15

⭐Why React Server Components Are Breaking Builds to Win Tomorrow
Большой статья про эволюцию подходов рендера React-приложений, начиная от клиентского рендера и заканчивая серверными компонентами. Расписано, какие были плюсы и минусы у каждого подхода и почему появился следующий подход.

Рекомендую к прочтению, если вы еще не читали подобных статей и интересуетесь тем, как развивается React.

Introducing JSR - the JavaScript Registry
Команда Deno сначала придумала свой рантайм для исполнения JS, а теперь представляют свой тулинг для реджистри с пакетами - JavaScript Registry (JSR). В основе JSR лежит идея, что тулинг для управления пакетами и реестр пакетами должен предоставлять лучший DX, чем текущие решения

NPM проделал большой путь в своем развитии, но сообщество проделало куда больший путь и хотелки разработчиков отличаются от того, что дает NPM. Например, до сих пор не решен вопрос, какой код нужно публиковать в npm - es5, es6 или может быть вообще не транспайлить код и поставлять исходники как есть?

Introducing runes
В Svelte используется свой компилятор для обеспечения реактивности компонентов. Вы просто объявляете переменную и используете ее в шаблоне, а Svelte компилятор сам делает её реактивной. Иногда все не так просто, но не в этом суть. В Svelte5 уходят от этого подхода и теперь реактивность будет явной. Чтоб было не скучно, названо это рунами.

В статье объясняется разница между новым и старым способом написания кода, а также на что это повлияет. Я недавно писал браузерное расширение с применением svelte и в целом согласен с мотивацией, описанной в статье: магическая реактивность завораживает, но хочется более явного API для этого и возможности использовать его не только в svelte файлах.

Puter: Internet OS and Desktop Environment in the Browser!
Вот сидите вы в своем ноутбуке, запускаете операционную систему, в ней браузер и потом думаете "эх, хочу вернутся операционную систему, но для этого надо выйти из браузера, что же делать?". И тут вам на помощь приходит Puter - десктопное окружение внутри браузера! Puter предоставляет собой много-оконное окружение с приложениями, которое очень похоже на современные операционные системы. Поиграйтесь в демке, выглядит действительно круто (о том, зачем такое нужно - позже).

В демке можно позапускать vscode, терминал, paint, файловый менеджер, камеру и многое другое. Можно даже, как я понял, вставить свое приложение. Интересно, что сам Puter написан на чистом JS + JQuery (вот мы и нашли пользователей JQuery). Ребята решили не брать какой-то сложный фреймворк для того, чтобы приложение работало быстро.

React Geiger
Библиотека для React, которая воспроизводит звук счетчика Гейгера на медленные рендеры React-компонентов. Т.е. вы подключаете её к себе на страницу и будете слышать пощелкивания каждый раз, когда случается рендер дольше определенного значения (50ms). На страничке проекта есть демо, где можно получить экспириенс, не устанавливая эту либу в свои проекты. Хотя я попробую на досуге подключить либку в рабочий проект.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Shiki: Syntax highlighter

Еще одна библиотека для подсветки синтаксиса в браузере. Поддерживает много языков и тем, а также кастомизируется через плагины и имеет интеграции в некоторые инструменты для генерации статических сайтов.

https://shiki.style

#development #javascript #library

The faster Lambda runtime - NodeJS or LLRT? We benchmarked.

Недавно Amazon сказали, что хотят использовать на своих лямбдах не node.js, а LLRT. LLRT - это эффективный рантайм на основе движка QuickJS. Amazon явно сделали это не просто так, а провели исследование эффективности LLRT в их кейсах, но публично их не показывали (или я не увидел). В этой статье автор пытается разобраться, действительно ли LLRT лучше

В целом статья делится на 2 части: сравнение движков (V8 и QuickJS) и сравнение скорости работы лямбды на node.js и LLRT

Итоги сравнения движков:
- V8 быстрее всех конкурентов по перформансу
- QuickJS весит так мало, что помещается на микрухи типа ESP32. QuickJS весит около 1 МБ, в то время как nodejs около 25-40 (в статье описано 150МБ, но по факту с сайта nodejs бинарь весит 25-40 в зависимости от платформы)

Если сравнивать скорость работы лямбды на двух рантаймах, то:
- LLRT инициализируется в разы быстрее (47ms против 770ms). А т.к. это лямбда, то за это время приходится платить (насколько я понимаю принцип работы AWS)
- Скорость ответа на запросы у LLRT также выше, чем у nodejs

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

https://learnaws.io/blog/node-vs-llrt

#development #javascript #performance #nodejs #llrt #benchmark

Modern Git Commands and Features You Should Be Using

Git, де факто, стандарт индустрии в области инструментов CVS и разработчики используют его каждый день. Однако, большинство разработчиков знают только основные команды - commit, push, pull, checkout.

В статье рассказывается о полезных фичах git, которые существуют относительно недавно: switch для перехода между ветками, restore для восстановления файлов, sparse-checkout для чекаута не всего репозитория, а только его части, worktree для одновременной работы над несколькими ветками и bisect для поиска коммита, в котором появилась проблема

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

https://martinheinz.dev/blog/109

#development #git #recommended

Voici.js - A Node.js library for pretty printing your data on the terminal

Библиотека для вывода таблиц текстом в терминал в node.js. Библиотека написана на Typescript и имеет много разных фич: стилизация таблицы, сортировка, подсветки, агрегация и многое другое. С одной стороны "зачем кому-то нужны таблицы в stdout", с другой, кому то это может быть полезно. Например, у нас в проекте есть скрипты на node.js, которые мы запускаем в CICD пайплайнах и там понятный человеку вывод важен.

https://voici.larswaechter.dev

#development #javascript #nodejs #library

The Magic in Shiki Magic Move

В тулах для презентаций есть анимация перехода между слайдами, которая автоматически определяет, как нужно переместить элементы с 1го слайда на другой. Это позволяет делать красивые анимации смены слайдов. И вот такую же штуку поддерживает shikijs для кода. Вы можете вставить 2 примера кода, например "до" и "после" рефакторинга, и shiki сам красиво анимирует переход одного в другой.

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

Звучит просто. Но непросто корректно найти пары элементов, которые двигаются (и вообще искать diff по тексту). В shiki используется подход от Google diff-match-patch, которая реализована как либа и создана как раз для нахождения дифов между текстом, которую Google делал для Google Docs (возьмите себе на заметку, если у вас есть подобная задача)

Задача с анимированием более простая, поэтому тут углубляться не буду: матчим дифф на токены текста (которые являются span'ами текста) и высчитываем изменения координат для токенов, которые должны переместится

Результат выглядит просто бомбически.

https://antfu.me/posts/shiki-magic-move

#development #javascript #animations #shikijs

Дайджест за 2024-03-18 - 2024-03-22

Shiki: Syntax highlighter
Еще одна библиотека для подсветки синтаксиса в браузере. Поддерживает много языков и тем, а также кастомизируется через плагины и имеет интеграции в некоторые инструменты для генерации статических сайтов.


The faster Lambda runtime - NodeJS or LLRT? We benchmarked.
Недавно Amazon сказали, что хотят использовать на своих лямбдах не node.js, а LLRT. LLRT - это эффективный рантайм на основе движка QuickJS. Amazon явно сделали это не просто так, а провели исследование эффективности LLRT в их кейсах, но публично их не показывали (или я не увидел). В этой статье автор пытается разобраться, действительно ли LLRT лучше

В целом статья делится на 2 части: сравнение движков (V8 и QuickJS) и сравнение скорости работы лямбды на node.js и LLRT

⭐Modern Git Commands and Features You Should Be Using
Git, де факто, стандарт индустрии в области инструментов CVS и разработчики используют его каждый день. Однако, большинство разработчиков знают только основные команды - commit, push, pull, checkout.

В статье рассказывается о полезных фичах git, которые существуют относительно недавно: switch для перехода между ветками, restore для восстановления файлов, sparse-checkout для чекаута не всего репозитория, а только его части, worktree для одновременной работы над несколькими ветками и bisect для поиска коммита, в котором появилась проблема

Voici.js - A Node.js library for pretty printing your data on the terminal
Библиотека для вывода таблиц текстом в терминал в node.js. Библиотека написана на Typescript и имеет много разных фич: стилизация таблицы, сортировка, подсветки, агрегация и многое другое. С одной стороны "зачем кому-то нужны таблицы в stdout", с другой, кому то это может быть полезно. Например, у нас в проекте есть скрипты на node.js, которые мы запускаем в CICD пайплайнах и там понятный человеку вывод важен.

The Magic in Shiki Magic Move
В тулах для презентаций есть анимация перехода между слайдами, которая автоматически определяет, как нужно переместить элементы с 1го слайда на другой. Это позволяет делать красивые анимации смены слайдов. И вот такую же штуку поддерживает shikijs для кода. Вы можете вставить 2 примера кода, например "до" и "после" рефакторинга, и shiki сам красиво анимирует переход одного в другой.

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

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Type system of the React compiler

Статья про систему типов в разрабатываемом компиляторе React Forget. В данной статье объясняется, как на основе анализа кода компилятор может понять, что используемые функции и переменные оперируют только примитивами и поэтому их не нужно оборачивать в useMemo, сохранив устройство немного ОЗУ и уменьшив размер поставляемого бандла.

Использование своей системы типов позволяет React'у не только оптимизировать код на этапе компиляции, но и проводить проверки корректности использования кода. Например, запрещать мутировать state из useState.

https://www.recompiled.dev/blog/type-system/

#development #javascript #react #reactForget

OpenTelemetry in Practice: Instrumenting JavaScript Apps for Tracing

Статья про интеграцию nodejs и браузерных js приложений в OpenTelemetry.

OpenTelemetry - это проект, который предлагает фреймворк для сбора, обработки и экспорта телеметрии (сигналов, трейсов, логов), и вокруг которого можно настроить разные бекенды для анализа телеметрии.

Если говорить простым языком, то OpenTelemetry позволяет реализовать в проекте хороший observability, когда вы, расследуя какой-то инцидент с прода и зная traceId одного из запросов, можете восстановить весь процесс обработки запроса пользователя от "клика на кнопку" и до запросов в базу. Причем, это все можно красиво визуализировать, агрегировать и по разному обрабатывать.

Вернемся к JS. OpenTelementry описывает протокол, по которому нужно передавать телеметрию, а также дает готовый sdk для подключения в nodejs и браузер, который отправляет базовую телеметрию (не уверен точно какую, но как минимум исполняемые http запросы должны логироваться). SDK для подключения, судя по всему, супер гибкое, поэтому чтоб подключить SDK надо установить около 10 npm пакетов и написать около 50 строчек инициализации.

В статье коротко рассказывается и показывается, как подключить OpenTelementry в nodejs и браузерное приложение, как локально поднять простой коллектор для данных и смотреть трейсы со своим приложений

https://marmelab.com/blog/2024/03/14/opentelemetry-in-practice-instrumenting-javascript-apps-for-tracing.html

#development #javascript #nodejs #opentelemetry #monitoring #sre

Type Predicate Inference: The TS 5.5 Feature No One Expected

В TS 5.5 появится автоматическое уточнение типов у функций-предикатов. Проще всего это объяснить на примерах

Typescript давно умеет уточнять типы в условиях: если мы будем проверять тип переменной в условии if, то в теле if переменная будет уточненного типа

console.log(value); // value: string | number

if (typeof value === "string") {
    console.log(value); // value: string
}

С функциями типа isString такое не работало, пока не добавили специальный синтаксис

function isString(value: unknown): value is string {
   return typeof value === "string";
}

if (isString(value)) {
  console.log(value); // const value: string
}

Однако, есть 2 проблемы: 1) нужно не забывать писать этот специальный синтаксис 2) TS не проверяет, действительно ли тело функции сходится с объявленной проверкой. Например, если случайно указать is number вместо is string и TS ничего не скажет на этот счет

В релизе 5.5 Typescript сам будет уточнять тип переменных в таких функциях

function isString(value: unknown) {
  return typeof value === "string";
}

if (isString(value)) {
  console.log(value); // string
}

И это работает даже в более сложных примерах

function isObjAndHasIdProperty(value: unknown) {
  return (
    typeof value === "object" &&
    value !== null &&
    "id" in value &&
    typeof value.id === "number"
  );
}

if (isObjAndHasIdProperty(value)) {
  console.log(value.id); // number
}

Однако, это все еще не будет работать для arr.filter(Boolean) т.к. Boolean - это не предикат. Но эта проблема решается установкой ts-reset

https://www.totaltypescript.com/type-predicate-inference

#development #typescript

Node.js: The Documentary | An origin story

Вышла документалка про node.js. Я еще не смотрел (но собираюсь посмотреть), но судя по навигации, документалка посвящена истории создания ноды: от появления самой идеи использовать v8 для рантайма, до драмы о разделении коммьюнити на 2 лагеря (io.js и node.js) и дальнейшего их воссоединения

https://www.youtube.com/watch?v=LB8KwiiUGy0

#development #nodejs #documentary #youtube

Дайджест за 2024-03-25 - 2024-03-28

Type system of the React compiler
Статья про систему типов в разрабатываемом компиляторе React Forget. В данной статье объясняется, как на основе анализа кода компилятор может понять, что используемые функции и переменные оперируют только примитивами и поэтому их не нужно оборачивать в useMemo, сохранив устройство немного ОЗУ и уменьшив размер поставляемого бандла.

Использование своей системы типов позволяет React'у не только оптимизировать код на этапе компиляции, но и проводить проверки корректности использования кода. Например, запрещать мутировать state из useState.

OpenTelemetry in Practice: Instrumenting JavaScript Apps for Tracing
Статья про интеграцию nodejs и браузерных js приложений в OpenTelemetry.

OpenTelemetry - это проект, который предлагает фреймворк для сбора, обработки и экспорта телеметрии (сигналов, трейсов, логов), и вокруг которого можно настроить разные бекенды для анализа телеметрии.

Type Predicate Inference: The TS 5.5 Feature No One Expected
В TS 5.5 появится автоматическое уточнение типов у функций-предикатов. Проще всего это объяснить на примерах

Typescript давно умеет уточнять типы в условиях: если мы будем проверять тип переменной в условии if, то в теле if переменная будет уточненного типа

Node.js: The Documentary | An origin story
Вышла документалка про node.js. Я еще не смотрел (но собираюсь посмотреть), но судя по навигации, документалка посвящена истории создания ноды: от появления самой идеи использовать v8 для рантайма, до драмы о разделении коммьюнити на 2 лагеря (io.js и node.js) и дальнейшего их воссоединения

https://www.youtube.com/watch?v=LB8KwiiUGy0

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Как в Node.js контролировать потребление памяти при обработке сетевых запросов

Статья на хабре от Тинькофф про потоковую обработку данных в node.js небольшими порциями. При обработке запросов расходуется память - ведь нужно все пришедшие реквесты где-то хранить перед их обработкой. Один из способов вызвать DoS - это отправить много очень тяжелых запросов на бекенд и тем самым вызвать у него падение по потреблению памяти. Поэтому в высоконагруженных проектах необходимо чутко относится к обработке запросов. В статье рассказывается, как обрабатывать запросы на node.js и не падать по памяти

Техника, о которой говорится в статье, одновременно и проста и сложна. Нужно спроектировать такой протокол передачи данных, чтобы не нужно было дожидаться получения всех данных для их обработки. Это открывает нам возможность обрабатывать данные потоками. В свою очередь, TCP-протокол поддерживает явное указание сервером количества пакетов, которые он может принять.

Суммарно это дает следующее решение: в node.js создается Stream, в котором указано количество данных, после которого приостанавливается наполнение Stream (эта отметка называется highWaterMark). Этот Stream обарабатывается через for await of и связывается с обработчиком request. Node.js видя, что request связан со стримом, у которого есть highWaterMark, отправляет клиенту по TCP-соединению информацию о том, сколько еще данных можно отослать.

Как итог: запрос обрабатывается потоково, nodejs не расходует лишнюю память.

Данная статья очень хороша тем, что объясняет и работу потоков в nodejs, объясняет немножко про TCP и показыает реальный кейс оптимизации nodejs приложения.

https://habr.com/ru/companies/tinkoff/articles/799709/

#development #nodejs #performance #stream #habr #recommended

Для подписчиков из Новосибирска: 9 апреля SRE-Митап в Новосибирске

https://meetup.tinkoff.ru/event/sre-on-the-road-novosibirsk/

Программа:
18:30 - 19:00 Регистрация участников
19:00 - 19:40 Вячеслав Хаверко, Паттерны отказоустойчивой архитектуры
19:40 - 19:45 Перерыв
19:45 - 20:25 Максим Снежков, Аварийное восстановление Kubernetes в Cluster API
20:25 - 20:30 Перерыв
20:30 - 21:10 Лев Алимов, SRE+GPT. Использование LLM в повседневной работе инженера
21:10 Нетворкинг

JavaScript Visualized: Promise Execution

Крутой визуализированный гайд по Promise. Короткий обзор про то, как работают промисы, как разбирается очередь микротасок и все это очень круто визуализировано

https://www.lydiahallie.com/blog/promise-execution

#development #javascript #Promise #guide #recommended