Ругался в сегодняшнем подкасте, поругаюсь и тут. Ребята из webpagetest грязно манипулируют цифрами 🙂

TL;DR в статье несколько утверждений
1 Клиентский рендер медленный (согласен)
2 Запускать JS поверх прилетевшего с сервера HTML быстрее (согласен)
3 Вас спасёт SSR (крайне не согласен)

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

Ну и вывод в статье do some googling for terms like "SSR" and "server rendering"

Но это так не работает. Серверный рендер не бесплатный и не мгновенный. В кэш всё не упакуешь. Если Твиттер начнёт генерировать динамические странички на сервере, с какой скоростью он будет отвечать? Я не знаю. Никто не знает, кроме инженеров Твиттера. Да, SSG нас спасает, но SSG работает только для статического контента. Динамический же контент мы можем разве что на зоны разбить и отдавать часть (лэйаут, например) как статику со множеством реакт-рутов, наполняемых на клиенте.

Как обычно, there are three kinds of lies: lies, damned lies, and statistics

Пока нет сил на технический пост про программирование, вот вам удивительное про микрофоны. Как писал тут микрофон нужно брать динамический, а не вот эти все разрекламированные геймерские конденсаторники, a la Blue Yeti. И тут вдруг поддержка откуда не ждали — и Blue и Elgato выпустили для стримеров динамические модели.

Blue Sona красавец подороже, со встроенным предварительным усилителем. Elgato Wave DX подешевле, без предвака, но с припиской, что бустер и не нужен.

Ну и конечно приписка радует supercardioid pickup pattern focuses tightly on your voice and rejects sound coming from all other directions. А раньше-то вы чего ждали, когда выпускали конденсаторники для неподготовленных помещений с кардиодой, больше похожей на восьмёрку?

Недавно обсуждали с одним высокогрейдовым программистом — что же такое динамическое программирование (DP)? Книжки по алгоритмам нам говорят, что есть такое вот загадочное программирование, которым решается задача о рюкзаке* (вот решение, запомни) или можно посчитать расстояние Левенштейна (вот решение, вызубри).

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

При этом обычно не даётся никакого универсального алгоритма, как решить с помощью DP любую задачу. Точнее, алгоритм такой — разбиваем задачу на меньшие подзадачи, решаем их, результаты мемоизируем и собираем ответ для исходной задачи. Похоже на «Разделяй и властвуй», но с неоднократным переиспользованием результатов каждого уровня.

И кажется мне, что сами задачи в полной мере и описывают принцип, потому везде через задачи и обьясняют DP. В чём проблема того же рюкзака? Если мы будем решать задачу жадно (берём на каждой итерации самую дорогую вещь, которая сейчас влазит в рюкзак), то решение может быть неоптимальным. Для примера, есть на полке айфоны и макбуки. Айфон занимает 1 позицию в рюкзаке и стоит 100k. Макбук занимает 4 позиции и стоит 200k. Вместимость рюкзака — 4 позиции. Жадный алгоритм говорит нам взять макбук. Динамическое программирование говорит: представь, что у тебя рюкзак на 1 позицию. Что туда влезет идеальное? А на 2 позиции? А на три? А на 4, что выгоднее — докинуть к максимуму из 3-х позиций ещё один айфон или взять макбук?
Итого DP даёт решение «4 айфона».

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

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

Желаю вам избежать DP-задач на собеседованиях.

CHAPTER 9: Design a web crawler

В публичный доступ вышло интересное и полезное обсуждение про web crawler. Советую вам заценить - Сергея UfoCoder сделал классную презентацию, где разобрал в деталях как работает поисковый робот. Так же обсудили на что стоит обратить внимание и какие возможные проблемы могут быть. Еще в самом начале Андрей показал нам артефакты из прошлого ❤️ Получилось очень лампово.

Видео уже на YouTube

PS поддержите пожалуйста нас лайком и хорошим комментарием на YouTube 🙏 Ваша поддержка помогает нам дальше заниматься этим

Всплыл тут вопрос — сколько памяти потребляет node.js. То есть конфигурируете вы VDS и всплывает вопрос, какой объём памяти нужно поставить в виртуалку.
Достаточно очевидно, что всё зависит от вашего приложения и нужно измерять его, но всё же есть у node.js такая особенность, что размер кучи в V8 задан конфигурацией и если вы вылезете за него, то случится OOM (heap out of memory). Потому все ребята с жирными бандлами (а в моём опыте больше всего потребляла всегда именно параллельная сборка тяжёлых проектов, а не рантайм) знают про ключик --max-old-space-size через который можно подкинуть памяти в кучу или ограничить её, чтобы словить OOM пораньше и устранить утечку. Молодое же пространство маленькое и особо ни на что не влияет, потому крутим именно old_space.

Однако есть интересный вопрос — а какой же размер кучи по умолчанию? Достаточно долго (до node.js 12) мы жили в парадигме, что у нас есть 1.34Gb кучи для 64-битных платформ. А дальше стало интересней. Во-первых нода научилась читать лимиты в cgroups. Теперь запуская ноду в контейнере вы автоматически получается соответствие размера кучи и лимита памяти контейнера. Во-вторых дефолтные лимиты изменились. Так как документации на дефолты нет, то сообщество просто померило их руками, забивая память в цикле и ожидая ошибки. Вышло вот так (для 64 бит):

Node.js Version Limit
----------------- -------
18.x 4.0 GB
17.x 4.0 GB
16.x 4.0 GB
15.x 4.0 GB
14.x 4.0 GB
13.x 2.0 GB
12.x 2.0 GB
11.x 1.4 GB
10.x 1.4 GB
9.x 1.4 GB

Вообще сколько я мерил рантайм на проектах — редко добивало даже до гигабайта, если не случалось утечки (а с утечкой нет смысла докручивать память, вы всё равно рухнете, позже, но рухнете). Как уже написал выше, гораздо критичнее память на сборке, тестах и прочем «параллельном» CI. Вот там нужно правильно подобрать и сервер и лимиты в самой ноде. В обычном же рантайме не забываем следить за метриками, потребление памяти должно быть пилообразным и относительно небольшим (хотя кто знает, что у вас там за рантайм, может вы числодробилку с мемоизацией запускаете).

Маттео Коллина тут завлёк многих докладом I would never use an ORM. Смотришь на тайминг и думаешь «ох, нифига себе, 40 минут уничтожения ORM, надо больше попкорна». Но это, к сожалению, не совсем так. На самом деле, ругает ORM Маттео только в первой части, во второй он рекламирует свой новый инструмент/платформу Platformatic. Погнали по тейкам:

ORM очень много обещают. Мол, используйте меня и будет у тебя красота и простота в коде.

Модели много на себя берут. Управляют хранилищем и связями, хранят данные в памяти, содержат бизнес-логику. Но мы уже переросли концепцию MVC и структурируем приложения по фичам, нам не нужны жирные модели.

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

ORM упрощают самую простую часть (описание схемы, миграции, простейшие запросы), но никак не помогают нам в решении сложных задач, которые нас настигнут позже. В конце концов, мы приходим к ручному написанию SQL и борьбе с типами.

Если мы общаемся с БД посредством ORM мы работает на минимальном уровне возможностей. Вместо всей мощи SQL мы используем какой-то упрощённый неявный срез фич. Например, PostgreSQL умеет работать с JSON-полями, но мы ждали годы, пока ORM дадут нам возможность строить по ним запросы.

Раз нам не нравятся повторяющиеся простые задачи и мы не хотим использовать ORM, то давайте просто сделаем платформу, где будет всё из коробки и нормально (тут он как раз презентует Platformatic).

Platformatic — это приложение поверх Fastify, построенное на плагинах. Все плагины доступны отдельно и их можно подключить в любое Fastify-приложение. Platformatic берёт на себя работу с БД, фактически это готовый бэкенд, который может отдавать REST и GraphQL и работать с любой популярной базой данных. Просто пишем миграции и иногда расширяем поведение плагинами, если чего-то не хватает.

Ну и в конце он задаётся вопросом — не написал ли он очередную ORM создав Platformatic? Решайте сами.

---

От себя добавлю, что независимо от того нравятся вам ORM или нет, я порекомендую к изучению код Platformatic. Маттео фигни не напишет.

Хорошая конфа намечается https://www.jetbrains.com/lp/javanoscript-day-2022/

Пополнение в семье WebKit — выкатилась публичная бета DuckDuckGo. На месте все фишки мобильного DDG с зачисткой кук и трекеров. Не забыли и кнопку Fire, вычищающую всё. И на десерт — плеер для YouTube без трекинга и рекламы. Ну и конечно, под капотом JavaScriptCore, а не бездушный V8.

Хотя у меня остаются подозрения, что это какое-то WebView.

Продолжается внедрение идей FaaS во всё подряд. Вот и Slack выкатил бету платформы для ботов, работающей на функциях, запускаемых в окружении Deno. Из плюсов Deno — не нужно транспилить ts в js.
Есть и сторадж с DynamoDB синтаксисом и воркфлоу для описания цепочек функций.
Можно строить сложных ботиков, которые крутятся полностью на инфраструктуре Slack

И тут я вижу минус, если ваши текущие боты имеют доступ к секретам, то перенос их напрямую в инфру Slack — это +1 вектор атаки.

На фоне боли разработчиков от Webpack Module Federation вспомнил как мы в Деньгах своё время организовали «настоящие» микросервисы вместо расределённого монолита микрофронтендов с хост-системой. Да, отказавшись от бесшовности и общего стейта, но с полной изоляцией каждого микросервиса и возможностью безболезненно обновлять shared-зависимости между лэйаутом и микрофронтом.

Мы разделили все бизнес-домены по принципу 1 фронт — 1 BFF. Каждый BFF не только обслуживал API как гетвей, но и занимался SSR. Отдельно мы поставили микросервис, который обозвали «сервисом обвязки» — он версионированно отдавал внешний лэйаут (шапка, меню, футер). Каждый фронтед-микросервис при рендере контроллера одновременно направлял сетевой запрос за обвязкой (по некоторым причинам там невозможно было обложиться кэшами) и финально склеивал два потока вывода (RxJS) в один общий, отправляемый в ответ браузеру.

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

Напомню что обновление на мажор какого-нибудь реакт роутера в Webpack Module Federation обычно предлагается примерно так:
1 Подготавливаем код всех модулей
2 Подготавливаем код хост-системы
3 Полностью закрываем сервис и делаем массовый релиз всех джунглей

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

Дополнительным плюсом нашей схемы было то, что при падении сервиса обвязки мы могли просто рисовать фоллбек шапки. А вот в Module Federation падение хост-системы накроет вообще всё. Распределённый монолит он такой.

Из документации свежего Next

React extends fetch to provide automatic request deduping, and Next.js extends the fetch options object to allow each request to set its own caching and revalidating rules.

https://beta.nextjs.org/docs/data-fetching/fundamentals#the-fetch-api-and-async-components

Если вы понимаете, зачем они творят такое непотребство, а ещё лучше имеете под рукой ссылки на конкретные публичные обсуждения и PR — велком в комментарии. У Next к сожалению все внутренние PR ссылаются на Slack и Notion.

Так, господин 🦜popuguy помог найти PR в Реакте.

https://github.com/facebook/react/pull/25516/files

UPD всё же очень жаль, что в PR не описана проблема и процесс принятия решения. Есть ощущение, что решали так, чтобы починилось у всех разом, без изменения кодовой базы. Хотя даже здесь мы видим «POST requests are not deduped so they have to be wrapped in cache() explicitly. »

Закрывая сегодняшнюю тему — подозреваю, что в Реакте патчили fetch чтобы из коробки решить вот эту проблему https://news.1rj.ru/str/melikhov_dev/80 .
Решили только с fetch и только с get-запросами. POST всё равно придётся заворачивать в cache() руками.
И, наверное, простить (и понять) хоть как-то можно, API не сломано (но неявно меняется поведение). А вот в next, к сожалению, пошли дальше и пропатчили API, внедрив свои параметры за нэймспейсом ‘next’ (я в первый момент глядя на код подумал, что это миддлвара какая-то).

Статья интересная и шутки хорошие

https://news.1rj.ru/str/msosnovfeed/431

Вот засада, когда ненужная в общем-то, но такая невинная (на первый взгляд) утилита (я конечно про JetBrains Toolbox, а не про zsh) поджирает процессор.
Ишью вот

Должен был это написать

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

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

Как сказали когда-то давным-давно мне мои друзья протестанты, которым я много и бескорыстно помогал — «Человек ты, Андрей, хороший, но всё равно попадёшь в ад». Важно не то, что ты действительно делаешь хорошего, важно вписываешься ли ты в рамки, выполнил ли ты базовую программу, после которой начинается твоя безупречность. Что ж, бог вам судья :)

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

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