Продолжается внедрение идей 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) поджирает процессор.
Ишью вот

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

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

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

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

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

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

А руки ещё помнят.

Кстати, JSX вырос из PHP-либы XHP, которая позволяла с помощью XML описывать HTML. В свою очередь XHP была построена на идеях JS-стандарта E4X, SpiderMonkey-реализацию которого мы и использовали в нашем XSLT-процессоре. Вот такая цикличность.

Постримим с ребятами из GeekBoards про клавиатуры. Попробую в очередной раз объяснить ,что не так с Keychron и что с этим можно сделать.

10.11 в 20:00 по GMT+3

https://holyjs.ru/talks/d1ba8d146dac4d30a49e5f252e6a8d19/

Вся эта шумиха с переездом с Твиттера на распределённый гипертекстовый векторный Mastodon напомнила мне про прекрасные времена Фидонета. Фидонет конечно был rulez 4ever, и никакая современная соцсеть не может сравниться с ним по вайбу (для меня). Если вы не застали (подозреваю, что старый тут только я), то вот вам краткий ликбез.

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

Вся сеть строилась на чистом энтузиазме. Ноды соглашались на вечно занятый ночью телефон (иногда поинты скидывались и ставили ноде вторую КРУГЛОСУТОЧНУЮ линию). Люди, имеющие доступ к дешёвому или бесплатному межгороду (или любой другой сети) поднимали хабы, и все вместе хабы образовывали бэкбон (хребет) сети, условие её выживания.

Фактически сеть могла работать даже на дискетах, привязанных к почтовым голубям — она была оффлайновой (да-да, FTN). Выглядело это так:

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

Всю эту красоту убила банальная штука — в стране ввели повременную плату за станционарный телефон. Да, Фидо можно было запустить и поверх TCP/IP, но никому уже это было не нужно. Кончилась эпоха.

Такое дело, next.js наконец-то обогнал Create React App в качестве инструмента по умолчанию для React-разработчика. Да, конечно, есть Vite, есть Remix, у всех свои причины для выбора, но речь не об этом.

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

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

Главный вопрос — бесплатной трансляции не будет, два раза ездить на конференции с одним докладом я не люблю, а значит нужно думать, что делать с этим добром дальше. Сесть за статью? Записать видос? Что-то, да надо будет сделать.

TIL FinOps

Financial Operations или Cloud Financial Operations. Ребята постарались вписать нормальную расшифровку, чтобы люди вроде меня не докапывались. Короче говоря, облака оказались такими гибкими в тарификации, что появились отдельные ребята, которые могут сесть с калькулятором и внятно ответить на вопрос — сколько денег мы заплатим вот за это облачное счастье и где можно срезать косты.

Поспорили вчера с Сашей Шушуновым — нужно ли проращивать типы насквозь от базы данных до фронта? Саша говорит, что нужно. Кент Доддс говорит, что нужно. А я за маппинг в DTO. И дядя Боб за DTO (кто бы сомневался). Да, удобно, когда имена полей гарантированно совпадают, но как же часто я вижу, как по системе гуляет модель со всеми её optional полями и реляциями. И на месте использования люди давят опциональность через ! чтобы TS не ругался (а что, я точно знаю, что здесь поле не пустое). Так если поле не пустое, то пусть структура DTO это и описывает. Если подтянули данные через реляцию — пусть DTO это описывает.

За пределами Data Access Layer я не хочу знать о структуре базы данных. Я хочу работать с чистыми данными, я не хочу видеть здесь модель, обвешанную методами. Представление данных на клиенте вообще может не совпадать с представлением в БД (как минимум, мы любим в UI работать с денормальзованными данными). А уж идея средствами ORM менять структуру БД под схемы вводит меня в ступор. Да, DX будет шикарный, но данные — это самое ценное, что у нас есть. И я хочу пересекать границу между данными и представлением максимально аккуратно.

Старый я. И вредный.

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