SuperOleg dev notes

Кстати first-class поддержка промисов в шаблонах не удивлюсь если первыми была у Marko.js, тег await - мейнейнеры фреймворка визионеры)

Вот и SvelteKit начали изящно стримить данные с сервера на клиент - https://svelte.dev/blog/streaming-snapshots-sveltekit

Для сериализации всего что только можно используется либа также от Рича Харриса - devalue

Не так давно (не знаю точно откуда сама идея пошла для мета-фреймворков) такой функционал в Remix добавили, Await + defer - https://remix.run/docs/en/v1/guides/streaming

Как работает фича с React и Remix хорошо и наглядно объяснено в этом gist'е.

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

Во многом это возможно именно из-за поддержи стриминга на уровне фреймворков - это await в темплейтах Svelte и Suspense у React - при использовании стриминговых API для рендеринга React имеет возможность для Suspense с промисами отправить на клиент fallback, а по завершении промиса отправить нужную разметку на клиент для обновления UI

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

Из клиентских фич React самое близкое сравнение это кажется startTransition API, тут также надо самостоятельно решить, когда необходима эта оптимизация, и в нужном месте она может дать очень хорошие результаты.

Очень хочется добавить такую фичу в tramvai, где уже есть свои особенности, для запросов используются Actions, которые имеют небольшой таймаут на выполнение на сервере, и информация об этом передается на клиент.
Если экшен не был выполнен на сервере - он автоматически будет запущен на клиенте, можно назвать это синхронизацией.
И вот тут основной минус, что надо долго ждать запуска клиентского экшена, загрузку всех ресурсов, самой страницы и ее гидрации.
Хорошее поле для улучшений)

Попалась новость - Vercel анонсировали Next.js Cache - https://nextjs.org/blog/next-13-2

Также это заанонсил Sebastian Markbage - https://twitter.com/sebmarkbage/status/1628845420121128965?t=Kcjyhz0u9gOePtgm69ubWg&s=19

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

В общем рекламируют такой ISR на стероидах, который отлично совмещается с Server Components.

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

Но вся эта громкая фича - это просто кэширование данных запросов...

Они уже манкипатчат fetch, и пошли ещё дальше, помимо дедупликации добавили в него разные стратегии кэширования.

Никто же до этого не использовал отдельный слой HTTP клиентов с кэшами, все фетчат направо и налево и страдают от медленных ответов.

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

А что вы думаете про анонс, и как далеко зайдет манкипатчинг fetch API?

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

Это очень вдохновляет, и мотивирует искать новые возможности как ускорить tramvai.

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

Веселый факт - на тяжелой странице, marko.js выдает больше RPS чем Next.js с использованием Static Site Generation!

По сути Next раздает статику медленее чем marko рендерит)

Но конечно это не совсем честное сравнение, так как в случае с SSG скорее всего будет использоваться CDN, и все будет гораздо быстрее.

У marko вообще ряд оптимизаций на уровне компилятора, плюс в документации описано отличие от реакта https://markojs.com/docs/why-is-marko-fast/#high-performance-server-side-rendering:
- react создаем vDOM, затем проходит по нему еще раз и рендерит HTML в строку
- marko рендерит HTML за один проход

И действительно во всех моих тестах marko примерно в 2 и более раза быстрее рендерит HTML, чем react.

При это по RPS marko выигрывает не меньше чем в 3 раза у tramvai и remix - и это вторая часть оптимизации - он делает минимум лишней работы на сервере.

Как я понял из ответа мейнера фреймворка - https://twitter.com/dylan_piercey/status/1561505479347449858?t=dOKFEf405DOPwOrFlqT6Pw&s=19 - они на этапе сборки компилируют нативный node.js сервер (то есть не используют фреймворк) и также в каком-то виде инлайнят роутинг.
И результаты очень крутые!

Так в чем секрет marko.js? На флеймчарте можно увидеть просто минимум работы, и сейчас это коротко разберем.

tramvai перешел на fastify, и тут все получше, но есть свой оверхэд на инициализацию дерева DI провайдеров под каждый запрос, и в итоге не намного опережает Remix под нагрузками

На сервере каждая миллисекунда работы важна и повлияет на итоговый RPS и latency нагруженного сервиса.

Пример флеймчарта Remix, на express.js сервере который делает достаточно много лишней работы

Привет!

Достаточно давно смотрел на бенчмарк фреймворков от builderIO, и был очень удивлен насколько быстро по ним работает marko.js - https://github.com/BuilderIO/framework-benchmarks#ssr-times

Наконец-то добрался попрофилировать что там происходит во время рендеринга на сервере.

Сравнивал marko.js, и remix, затем добавил tramvai в бенчмарк, смотрел все на дефолтном примере с /dashboard, потом на эту же страничку добавил очень много компонентов что бы посмотреть и на тяжелом рендере что происходит.

tramvai и remix - оба делают минимум действий вокруг реакта, можно сказать что это чистый renderToString плюс работа серверного фреймворка (конечно фреймворк-специфичные детали есть, но все не так плохо как у next.js, там свой прикол с post-процессингом HTML перед отправкой клиенту, чем она больше тем хуже - https://github.com/vercel/next.js/issues/35797)

Что интересного по итогу:

Привет!

Интересный кейс, про подходы мета-фреймворков для загрузки данных, и немного мыслей по теме.

В Next.js улучшают поддержку SEO, если надо будет формировать мета данные динамически - для этого будет отдельная функция - загрузчик.

При этом, в нексте уже есть возможность загрузки данных в самих компонентах, благодаря Server Components (серверные компоненты могут быть async, клиентские могут использовать экспериментальный хук use) и подходу render-as-you-fetch.

Это обсудили в твиттере, что делать если нужны данные из одного и того же запроса в компоненте и загрузчике SEO данных.
Решение - экспериментальное cache апи реакта - https://twitter.com/leeerob/status/1619812802453188608?t=W_QqKVZeKSFPTeORs8XBlg&s=19

Remix кстати эту проблему решает по другому, прокидывая данные из загрузчика для страницы в meta функцию.

Этот cache под капотом дедуплицирует вызов функции по аргументам.

И для render-as-you-fetch с server components это наверное нормальное решение что бы избежать дубликатов и водопадов запросов, хотя и решаемое на уровне http клиентов (например tinkoff-request https://tinkoff.github.io/tinkoff-request/docs/plugins/cache-deduplicate.html)

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

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

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

Также есть взгляд немного с другой стороны, в tramvai основной механизм загрузки данных - экшены, которых можно сколько угодно добавить для страницы, и они будут выполнены параллельно.
Прямой связи между данными из экшена и компонентом страницы нет, и основным транспортным каналом как раз является встроенный в трамвай стейт-менеджер.
Конечно минусы и тут есть, например это лишний бойлерплейт для простых кейсов, в ряде случаев можно решить использованием react-query вместо стейт-менеджера.
Также встречал сложные кейсы, когда экшены вложены друг в друга многократно (как правило связано со сложностью логики этого кейса)

Если говорить про кейс с SEO, благодаря DI, в трамвайных экшенах можно менять мету вручную, используя созданный для этого сервис (привет хорошим практикам из Angular) - то есть гибче просто уже некуда.

По итогу, не могу сделать какие-то полезные выводы - все делают по разному, и все эти механизмы сделаны не просто так, имеют и плюсы и минусы.

Очень интересно как вы решаете сложные кейсы бизнес-логики в приложениях написанных на мета-фреймворках.

Алгоритм работы механизма отображения error UI в Remix не сложный, изящный, с важным минусом который кажется никак не решить снаружи реакта:

- В основе лежит Error Boundary, но скорее его можно назвать Universal Error Boundary - важное отличие в том, что компонент может принимать объект ошибки error снаружи, как пропс. Пример в репе трамвая - https://github.com/Tinkoff/tramvai/blob/main/packages/tramvai/react/src/error/UniversalErrorBoundary.tsx
- Что бы избежать ошибок гидрации из-за рассинхрона разметки, эту error надо сериализовать и передавать на клиент. Пример простых хэлперов что бы перегнать объект ошибки в простой объект и обратно - https://github.com/Tinkoff/tramvai/blob/main/packages/modules/render/src/shared/pageErrorStore.tsx#L11
- Самое главное, и тут как раз скрывается не приятный но простой хак, нам нужно получить эту ошибку. Единственный универсальный способ сделать это - try/catch для renderToString или хэндлеры ошибок у renderToPipeableStream. Но получение этой ошибки означает, что рендер упал - и его придется делать повторно.

При повторном рендере, мы где-то уже храним ошибку, и можем передать ее в пропсы Error Boundary, и не рендерить компонент второй раз.

Важный момент! Мы только предполагаем, что ошибка была где-то в компоненте страницы, но этот механизм никак не гарантирует, что второй рендер тоже не упадет - и тут как раз надо иметь некий Root Error Boundary, который мы бы отдали в ответ на любую неперхваченную ошибку.

Почему только сейчас вспомнил про эту тему - вчера мне стало интересно, что там нового у Next.js 13 и Remix по обработке ошибок, оба перешли на API для стримингового рендеринга реакта, и копаясь в исходниках Remix увидел что много всего изменилось, в том числе по Error Boundaries.

Сначала решил, что нашли какой-то способ, возможно с Suspense, не делать повторный рендер - но нет, докопался до мест, где рендер делается второй и где-то даже и третий раз)

Из интересного, оба фреймворка поддерживают вложенный роутинг, и вот для того что бы под ошибку найти самый ближайший Error Boundary, они кажется трекают какой именно роут рендерился на данный момент. Но может быть и просто берется самый вложенный текущий роут, дальше копать не стал.

Ждем, что предложит нам React в будущем, или какие-то новые крутые паттерны от сообщества, как сделать обработку ошибок проще и производительнее.

Очень интересен ваш фидбек, как обрабатываете ошибки, или может быть кто-то глубоко понимает механизмы того-же некста, и сможет раскрыть тему?

Спасибо за внимание!

Привет!

Про обработку ошибок рендеринга при SSR.

Сразу начну с примеров обработки таких ошибок.

Во многих мета-фреймворках (Next.js, Remix, SvelteKit, Nuxt.js) есть простой способ отобразить UI при ошибках в компонентах. Там где поддерживается вложенный роутинг, этот error компонент можно добавлять на уровне конкретных страниц, и таким образом рендерить error UI локально (поиграться с примером на Next.js можно тут - https://app-dir.vercel.app/error-handling/books). Как правило, дополнительно всегда есть общий для всех дефолтный компонент - страница ошибки, который будет использован в том числе если ошибка произошла вне React (например в любом месте в серверном обработчике запроса).

Какие именно ошибки вообще можно и нужно обрабатывать? Если мы говорим про роуты, вот два основных кейса:

- expected ошибки, связанные с загрузкой данных для роута - когда надо программно выбросить 404 или 500 ошибку и отобразить подходящий UI, это область ответственности meta-фреймворка, ошибку легко поймать
- unexpected ошибки, по сути любой throw внутри React компонента страницы, и такую ошибку достаточно сложно обработать

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

У нас же есть Error Boundary и все ок? - к сожалению нет, он поймает только ошибки в рантайме браузера, если например throw произошел при обработке клика от пользователя.

Остаются ошибки при серверном рендеринге и ошибки гидрации.

Так, мы копнули глубже (https://github.com/reactjs/rfcs/blob/main/text/0215-server-errors-in-react-18.md, и узнали что с 18 версии реакта Suspense тоже обрабатывает ошибки, как раз на сервере и при гидрации.

Если коротко, Suspense при ошибке вложенного компонента на сервере отрисует fallback компонент, сериализует ошибку для передачи на клиент, затем на клиенте, если этот же компонент снова выкинет исключение, Suspense не будет его обрабатывать, и оно попадет в ближайший Error Boundary.

Тут тоже есть нюансы:

- Если используем renderToString на сервере - никак не сможем залогировать ошибку, изменить код ответа, все произойдет “молча”. Только на клиенте, если использовать hydrateRoot, можно залогировать серверную ошибку в onRecoverableError
- С renderToPipeableStream все уже лучше, есть обработчики ошибок, у нас почти полный контроль, но мы все-равно не знаем в каком именно компоненте произошла ошибка (парсить стек-трейс этой ошибки неблагодарное дело), и в fallback UI не имеем прямого доступа к объекту этой ошибки
- Не все пользователи перешли на React 18, мета-фреймворки еще не могут завязаться на этот механизм
- В идеале хочется рендерить один и тот же fallback и в Suspense, и в Error Boundary - но как минимум у Suspense фаллбэка нет доступа к ошибке, уже не получится отрисовать аналогичный UI

По итогу, Suspense в связке с Error Boundary вполне подойдет для повышения надежности и производительности (Selective Hydration) каких-нибудь островков на страницах, таких как микрофронтенды (хотя и тут много чего надо учитывать вне реакта, например падение запроса за JS кодом микрофронта на сервере - надо отрендерить фаллбэк, перезапросить на клиенте, будет много кастомного кода), но реализовать полноценный Page Error Boundary только с этими механизмами не получится.

Так как же устроен этот механизм у Next.js, или у Remix?

Я первый раз исследовал эту тему когда добавлял Page Error Boundary в tramvai в прошлом году - https://tramvai.dev/docs/features/error-boundaries#specific-fallback, и смотрел как раз в исходники Remix, которые порадовали своей простотой и комментариями, в отличие например от некста.

Привет!

Давно хотел поделиться накопленным за последний год опытом оптимизаций и масштабирования 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

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

С наступающим, ребята!
Спасибо за ваш интерес к каналу, возможность делиться мыслями вслух на такую аудиторию - очень волнительно и бесценно ❤️

Привет!

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

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

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

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

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

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

SuperOleg dev notes pinned «Привет! TLDR: Ищу коллегу в техническую команду! Уже почти три года я работаю в Тинькофф в технической команде над SSR мета-фреймворком https://tramvai.dev Мне всегда было интересно работать над классным продуктом, делать сложный UI, улучшать производительность…»

Отдельно открыл для себя паттерн разработки, которым раньше пользовался неосознанно:

- Начинаю с ADR на новую фичу
- Далее создаю минимальное example приложение со всеми возможными кейсами
- Реализация фичи, вся разработка наглядно сразу в example приложении
- Практически из коробки получаем интеграционные тесты (в самом простом случае, снапшоты на HTML страничек example)
- И также есть готовые примеры кода, на основе которых легко сделать документацию

Спасибо за внимание!

Делитесь вашим опытом и мыслями в комментариях.

Учитывая уже развернутый сервис imgproxy, я решил делать Image компонент поверх этого сервиса - это закрыло вопросы лишней нагрузки на SSR приложения, оптимизации под разные форматы, отдачи нужного формата в рантайме без тега picture (что позволяет сделать очень простую разметку).

Еще не решенная проблема этого выбора - невозможность использовать сервис при разработке, для изображений на localhost.

.avif формат у нас был отключен из-за высокой нагрузки при генерации изображений в этом формате, было интересно разобраться в проблеме, даже помогли немножко улучшить сервис - https://github.com/imgproxy/imgproxy/issues/938.
Оказалось, что для достижения сравнимого качества изображения, для AVIF надо указывать значительно более низкий уровень качества при оптимизации, хорошее сравнение форматов можно найти тут - https://www.industrialempathy.com/posts/avif-webp-quality-settings/

В итоге, после точечной настройки, мы подключили AVIF, и в среднем, с примерно одинаковым качеством, это снизило размер итоговых изображений на 30-50% по сравнению с webP.

Следующий кейс - автоматическое сохранение пропорций, вычисление aspect-ratio.
На примере некста, логику получения размера картинки можно встроить в сборку - https://github.com/vercel/next.js/blob/canary/packages/next/build/webpack/loaders/next-image-loader.js.
В tramvai я добавил простой лоадер, который переиспользует логику file-loader (компромисс, т.к. по хорошему надо использовать Asset Modules), но при именованном импорте отдает объект с данными об изображении, которые необходимы для сохранения пропорций:

jsx
import { image } from './image.png';

const { src, width, height } = image;

<img src={src} width={width} height={height} />

По аналогии с next/image, добавил в компонент несколько вариантов верстки (и без необходимости поддерживать старые браузеры и наличии aspect-ratio, верстка невероятно простая):

- адаптивная, но не больше размера изображения (intrinsic)
- резиновая под размер контейнера (responsive)
- фиксированный размер (fixed)
- заполняющая доступное пространство (fill)

Если для intrinsic и fixed изображений достаточно учесть только плотность пикселей на экране, и передать в srcset 1x и 2x изображения, то для оптимальной responsive и fill верстки srcset должен содержать изображения под совершенно разные размеры экранов.

По этой причине, отдельной задачей было исследовать аналитику посещения наший приложений на tinkoff.ru для создания минимального но в то же время полного списка экранов, которые мы будем учитывать в srcset при генерации изображений.

Пример размеров из этого списка:

- 720px - популярная ширина мобилок 360px плюс 2x плотность пикселей
- 1366px - популярная ширина на десктопе
- 3840px - еще одна популярная ширина на десктопе, 1920px плюс 2x плотность пикселей

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

Еще из интересного, простые и удобные абстракции:

- Свойство quality - позволяет при необходимости сконфигурировать оптимизацию через imgproxy более высокого качества, или наоборот более низкого
- Свойство priority - по умолчанию делаем все изображения c loading="lazy", но можем повысить приоритет и убрать этот атрибут, а с самым высоким приоритетом автоматически добавляем preload link на страницу для этой картинки (тривиальная задача для SSR фреймворка), что идеально подходит для Largest Contentful Paint изображения

Это был очень интересный опыт, и интересно как дальше будет развиваться новый Image компонент.

Например, в будущем я планирую отвязать его от imgproxy, и перенести в список публичных пакетов, которые публикуются в open-source.

Также, надо будет выбрать хороший способ создания blur плейсхолдера для изображений.

Не увидительно, что фреймворки стараются упростить эти вещи для пользователей, и различные Image компоненты можно увидеть у Next.js, Nuxt.js, Remix, SvelteKit, Gatsby, и даже в каком-то ограниченном виде в Angular (ограниченном, т.к. в рантайме у SSR фреймворков больше возможностей, чем у Angular на этапе сборки)

Такой компонент мы решили добавить и для нашего фреймворка tramvai

Документация к next/image во многом является спецификацией компонента, покрывает множество кейсов, и стала для меня отличным референсом.

Важная часть работы с изображениями - это оптимизация и конвертация в оптимальный формат.
В самом простом случае, можно сделать это вручную, с помощью таких сервисов как Squoosh.
Более продвинутый способ - оптимизация на этапе сборки, например с помощью image-webpack-loader.

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

Решить эти проблемы проще всего в рантайме, и тут я знаю два варианта:

- Использовать отдельный сервис для оптимизации изображений - например в Тинькофф мы используем замечательный https://imgproxy.net/
- Использовать библиотку для оптимизации на сервере самого приложения - например https://github.com/GoogleChromeLabs/squoosh

Работа с изображениями - это тяжелый вычислительный процесс, и кажется не очень разумным делать такое в рантайме SSR сервера, которому и React в HTML отрендерить не так просто.

Но на самом деле, проблема нагрузки актуальна и для отдельного сервиса, и для нее есть отличное решение - CDN.
Обработанные изображения можно агрессивно кэшировать, и в разы снизить нагрузку на приложение.

Важный момент по поводу кэширования - CDN должен учитывать кодировку изображения, если по одной и той же ссылке к примеру imgproxy отдаст .avif для Chrome или .webp для Safari.
Для этого надо передавать заголовок Vary: Accept в ответе с изображением, и настроить CDN на поддержку этого заголовка, в этом случае кэш будет сохраняться отдельно для каждого формата, и CDN будет отдавать подходящий формат с учетом заголовка Accept запроса из браузера.

Next.js обрабатывает изображений в рантайме, т.е. вся нагрузка приходится на приложение.
В первую очередь это удобно для разработчиков - не нужно поднимать и поддерживать отдельный сервис вроде imgproxy, все работает из коробки.
Второй момент, при деплое Next.js приложений через Vercel, ваши приложения будут находится за CDN, что позволяет кэшировать и страницы, и статику, и изображения, которые отдает приложение.
Для self-hosted деплоя придется проксировать запросы за картинками через CDN на приложение самостоятельно.

Скорее всего, Next.js также сохраняет изображения и страницы в файловой системе, и CDN тут только ускорит доставку, так далеко в исследовании я не заходил.

Хочется рассказать, что интересного было в разработке аналогичного решения.