Раз уж пишу про обновление документации effector, то расскажу, что сейчас сообщество активно пишет новые статьи и улучшает уже написанные!

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

Сейчас я не вкладываю много сил в документацию, так как недавно участвовал в программном комитете Podlodka React Crew #2, а также продолжаю дописывать контент для frontend.vision и активно стараюсь не выгореть.

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

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

Вообще, это подход так называемого RAG (Retrieval-augmented generation), но вместо использования полноценного инструмента я собрал свой RAG дома на коленке используя NodeJS + SQLite запуская в CLI.

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

Если интересно, расскажу как это работает подробнее

Я каким-то образом пропустил Rust 1.85

Язык перешел на новую стабильную версию синтаксиса Edition 2024

https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html

Системы эффектов

Недавно послушал выпуск Подлодки про "Системы эффектов в языках программирования" и решил поделиться некоторыми рандомными рассуждениями на эту тему.

"Окраска" функций

"Окраской" функций называется некоторая декларация эффектов, содержащихся в функции.

В JavaScript есть 2 варианта "окраски" функций:

- async — обозначает, что функция асинхронная и позволяет использовать внутри неё оператор await
- * — обозначает, что функция является генератором и позволяет использовать внутри неё оператор yield

Fun fact: эти 2 варианта можно скомбинировать, чтобы получить AsyncIterator, который можно перебирать оператором for await...of.

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

Обработка исключений

В Java есть оператор throws, позволяющий "окрасить" функцию эффектом выброса определённого типа исключения и на этапе сборки удостовериться, что эти исключения обработаны.

JavaScript/TypeScript не позволяет типизировать исключения (разве что задокументировать их с помощью JSDoc или TSDoc), но теоретически эту проблему можно решить знаменитой монадой Either.

Чистота функций

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

В самом JavaScript нет языкового средства для выражения чистоты функции — то есть отсутствия в ней эффектов, хотя было бы классно использовать это знание, например, для исполнения кода во время сборки (как, например, c babel-plugin-macros).

В документацию effector.dev подъехал ПР

Теперь в навигации есть красивый переключатель разделов, спасибо @senzujuju

https://github.com/effector/effector/pull/1232

Знаете, когда 10 лет опыта в IT вложены не только в карьерный рост, но и в крутые сторонние медиапроекты и создание качественного контента? Вот Андрей Смирнов — это как раз такой случай.

Что он уже успел:

Уже 9 лет в IT-менеджменте — управлял людьми в X5 Tech, IPONWEB и Rambler.

Ведёт аж два подкаста: Frontend Weekend и «600k в секунду». Правда, второй уже давно пора переименовать в «1M в секунду» — инфляция, что поделать.

Организовал свою первую конференцию по софтовым навыкам Soft Weekend.

Регулярно выступает на крупнейших конференциях: TeamLead Conf, HolyJS, Frontend Conf, CodeFest и других.

Участвует в программных комитетах CTO Conf, Podlodka Teamlead Crew и ИТ-Пикника.

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

Например, что мне зашло:

- «Как придумать идеальную тему для доклада» 
- «Стоит ли доверять интуиции?»
- «Технические навыки у управленцев?»

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

Рекомендую подписаться.

Зацените какая уязвимость в Next.js

https://security.snyk.io/vuln/SNYK-JS-NEXT-9508709

Уже не первый раз вижу статьи раскрывающие проблему окрашивания функций в разные цвета.

Если коротко:

async function red() {}
function blue() {}

Мы не можем просто так вызывать асинхронные red внутри обычных синхронной blue функциий, а точнее дождаться результата.
Нам нужно "перекрасить" нашу синхронную функцию в асинхронную, добавив маркер async, что повлияет на код использующий эту функцию, что в свою очередь потребует "перекрашивать" и этот код тоже, и так далее вверх по стеку вызовов.

Энтони показывает как можно обобщить работу с синхронными и асинхронными функциями с помощью библиотеки quansync и генераторов.

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

https://antfu.me/posts/async-sync-in-between

О, супер штука.
Я пока не потрогал, но концептуально мне очень нравится.

В мире opensource есть два основных подхода работы с пакетами:
А. npmjs-like
Б. go-like

Подход А — исходники пакета лежат где-то в git-репозитории (обычно github), через CI собираются и публикуются в сторонний реестр. Этот реестр гарантирует, что версия пакета не будет удалена, даже если с репозиторием что-то случилось.

Но это, вполне может вызвать расхождения между кодом в репозитории и кодом в реестре. В общем-то, ничего не мешает во время публикации, добавить любой код в бандл.
Частичное решение этой проблемы — NPM Package Provenance.
https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/

Подход Б — работать без реестра, выкачивать код непосредственно из git-репозитория. Для гарантии сохраняются хеши версий, чтобы нельзя было подменить код в ветке или git-tag и таким образом внедрить уязвимость.
Но, в случае удаления репозитория, все зависимые проекты сломаются.

Новый тул, является дополнением к первому подходу npmjs-like. Он предлагает возможность проверить, собирается ли из исходников тот же код, что лежит в реестре.
Что может существенно повысить доверие к разработчикам.

https://blog.vlt.sh/blog/reproducibility

Вы наверняка слышали про Rspack — альтернатива Webpack, но на Rust и с совместимостью по плагинам и конфигам.

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

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

Максимально актуально в связи с переездом экосистему на ESM, в ситуациях, когда два пакета имеют общую зависимость, но один пакет получил CJS версию, а другой ESM, в итоге в бандле две версии, странные плавающие баги и подобное.

https://rsdoctor.dev/blog/release/release-note-1_0

Из интересных проектов использующих Rspack экосистему — Lynx

Собирает React проект в Native приложения для мобилок.
Из любопытного: имеет кастомные директивы "background only" и "main thread" для выполнения функций в разных потоках.

https://lynxjs.org/react

Очень любопытный проект

Ходит на сайт с девтлузами React и строит граф зависимостей компонентов на странице.

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

https://react-explorer.com/

В Next.js 15 убрали автоматическое кеширование fetch().
Перестать манкипатчить стандартные методы — движение в верном направлении.

Взамен появился "use cache":
https://nextjs.org/docs/app/api-reference/directives/use-cache

А также cache() в React 19:
https://react.dev/reference/react/cache

А статья от Авроры показывает как использовать cache() для мемоизации вызовов экшенов

// When using cache(), the return value can be cached/memoized per render across multiple server components
const getComments = cache(async (postId: string) => {
  return fetchedData // actual implementation here
});

Но использовать его можно только в компонентах, еще и без await:

export default async function PostPage({ params }: { params: Promise<{ postId: string }> }) {
  const { postId } = await params;

  // Prefetch the comments, but don't await the promise, so it doesn't block rendering
  getComments(postId);

  return (
    <div>
      <h1>Post: {postId}</h1>
      <Suspense fallback={<div>Click Me Load More post...</div>}>
        <Post postId={postId} />
      </Suspense>
    </div>
  );
}

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

https://aurorascharff.no/posts/avoiding-server-component-waterfall-fetching-with-react-19-cache/

Насколько мне известно, появление поиска в ChatGPT, Google Grounding Answers, Claude Web Search сильно меняет рынок поисковиков.

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

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

https://paulstamatiou.com/browse-no-more

Уязвимости в NextJS

Я думаю уже почти все слышали про уязвимость в NextJS, которая позволяет при запросах обходить миддлевары, и например, пропускать обработку авторизационных токенов и прочие серверные проверки. Уязвимость очень проста в эксплуатации, достаточно прокинуть http-заголовок x-middleware-subrequest, которая пропускает указанные миддлевары. Подробнее почитать можно в блоге Рашида Алама.

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

Cache poisoning (дословно, отравление кэша) - это атака, при которой обычным пользователям отображается вредоносный ответ на основе манипуляций с веб-сервером и кэшем.

Кэш позволяет отдавать идентичный ответ пользователю, который сделал аналогичный запрос. Как понять, что запрос аналогичный? У запросов должен быть одинаковый кэш-ключ, который обычно формируется на основе различных компонентов: тип запроса, хост, pathname, некоторые http-заголовки (конечно этих параметров может быть намного больше). Если ключ совпадает, то отдается сохраненный результат из кэша, если нет - то запрос начинает обрабатываться сервером.

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

Вот и мы нарвались на такую уязвимость в нексте (CVE-2024-46982). Если кратко, у NextJS в рамках page router-а есть режим SSR через функцию getServerSideProps, которая подготавливает данные в формате JSON для страницы. Для этого некст при заходе на страницу отправляет запрос по пути /_next/data/.... Но есть внутренний query-параметр ?__nextDataReq=1, при добавлении которого к странице возвращается только JSON-данные для нее. И этот query-параметр не является частью ключа для кэша. Условно https://a.com и https://a.com/?__nextDataReq=1 будут иметь один ключ. Если результат второго запроса сложить в кэш, то у всех пользователей вместо главной страницы будет открываться JSON с данными.

Сам по себе getServerSideProps является динамическим и в кэш ничего не складывает. Но еще есть внутренний http-заголовок x-now-route-matches, "включающий" SSG (server side generation) режим некста, который складывает результаты в кэш. Понимаете к чему я веду? Уязвимость заключается именно в этом и с помощью комбинации ?__nextDataReq=1 + x-now-route-matches и одного запроса можно сломать любую динамическую страницу приложения, путем складывания в кэш JSON-данных для страницы и отдачи их вместо html-контента.

Более того, в этот JSON часто попадают значения http-заголовков, поэтому в него можно положить произвольный текст. А с учетом того, что запросы продолжают отдавать content-type равный text/html, то получаем еще и XSS абсолютно для всех пользователей, которые просто зайдут на страницу.

Подробнее про это можете почитать в блоге все того же профессора Рашида https://zhero-web-sec.github.io/research-and-things/nextjs-cache-and-chains-the-stale-elixir

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

Блокировки, блокировки, блокировочки...

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

Но вот не задача, почему то (sarcasm) подсети этого хостинга начинают блочить провайдеры...

Смачно выругавшись начинаем искать варианты:

1. Переехать значит на православный хостинг и платить x100500 деняг
2. Купить на православном хостинге VPS, поставить там nginx в режиме stream и надеяться, что хостинг не заблокируют на уровне магистрали.

Для тех кто выбрал второй вариант, все просто.

1. Ставим nginx с поддержкой stream
2. Добавляем в nginx.conf

...
stream {
    upstream k8s_https {
        server ваш_ip:443;
    }

    server {
        listen 443;
        proxy_pass k8s_https;
    }
}
...

В отличие от стандартного http {} блока, stream работает на уровне TCP, а не HTTP.
Он не трогает заголовки, не читает Host, не парсит User-Agent
Он просто берёт входящий TLS-трафик и тупо прокидывает его дальше.

При этом это работает охуительно быстро, в отличии от обычного proxy_pass

Никакого overhead, никакой нагрузки на CPU, ничего не разбирается, не кешируется и не мутируется.
Это как туннель, только без OpenVPN и танцев с бубном.


BEARlogin dev — подпишись!
#блокировки #proxy #devops