Виноват тут не шлюз. Виноват сервер, который исходил из того, что каждый запрос приходит ровно один раз. В сети, где теряются ответы, это допущение неверно всегда.

Идемпотентность — свойство операции, при котором повторное выполнение приводит к тому же состоянию, что и однократное. Сам ответ при этом может отличаться: повторный DELETE вернёт 404 вместо 200, и метод от этого идемпотентным быть не перестаёт. У HTTP это закреплено на уровне методов: RFC 9110 относит к идемпотентным PUT, DELETE и безопасные методы, а POST идемпотентным по своей природе не является. Бизнес-операции почти всегда отправляют именно через POST.

Клиент не может отличить «сервер не получил запрос» от «сервер выполнил операцию, но ответ потерялся», поэтому повтор придёт в любом случае.

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

Проверка «посмотреть и вставить» неатомарна: два одновременных повтора оба увидят отсутствие ключа. Нужен уникальный индекс или условная запись.

Запись в базу и отправка в очередь в одну транзакцию не помещаются. Обёртывать сетевой вызов в BEGIN и COMMIT вредно вдвойне: корректности не даёт, а пул соединений выедает.

Transactional outbox решает это одной таблицей: событие пишется в той же транзакции, что и бизнес-запись, а отдельный процесс доставляет его в очередь.

Почему повтор неизбежен

Сеть отказывает так, что установить факт доставки невозможно в принципе. Есть три типовых сценария, и внешне они неразличимы:

• Сервер обработал запрос, но ответ потерялся по дороге назад.
• Сервер всё ещё считает, а у клиента уже сработал таймаут.
• Балансировщик повторил запрос сам, никого об этом не уведомив.

Для GET повтор безвреден. Для POST /payments это второе списание. Отсюда и правило: одна логическая операция должна приводить к одному записанному итоговому состоянию, сколько бы раз её ни отправили. Осознанно новая операция обязана прийти с новым ключом.

Два способа сделать ручку идемпотентной и один в довесок

Способ первый: ключ идемпотентности

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

Три детали, на которых ошибаются чаще всего. Ключ генерирует клиент, а не сервер: смысл в том, что сервер сам по себе не отличит новый запрос от повтора. Ключ должен быть с высокой энтропией, обычно это UUID v4; выводить его из изменяемого или малоразнообразного поля вроде номера клиента нельзя, потому что это повышает риск коллизии и переигрывания чужой операции.

И последнее: повтор должен получить тот же самый ответ. Если первая попытка вернула 201 с идентификатором платежа, то и повтор возвращает те же 201 и тот же идентификатор, а не 409 и не пустую двухсотку. Иначе клиент решит, что операция не прошла, и попробует ещё раз.

Способ второй: сделать операцию идемпотентной по смыслу

Иногда ключ не нужен вовсе, потому что семантику можно спроектировать идемпотентной с самого начала. Классический пример — PUT /users/42, который задаёт полное представление ресурса: отправьте его дважды, и состояние будет одним и тем же.

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

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

Довесок: оптимистичная блокировка

Этот приём идемпотентности не даёт и в списке стоит по другой причине. Ключ защищает от повторов одного и того же запроса, но ничего не делает с двумя разными запросами, которые правят одну запись. Здесь работает проверка версии: клиент присылает версию, которую видел, а сервер отклоняет обновление при несовпадении.

Обратите внимание, что проверка версии живёт внутри самого UPDATE. Разнести её на отдельное чтение и последующую запись означало бы воспроизвести ровно ту гонку, о которой пойдёт речь в следующем разделе: два запроса с одной устаревшей версией оба прошли бы проверку и оба записали бы результат. Идемпотентным одиночный запрос этот приём не делает, зато закрывает частый источник задвоенных эффектов: двух писателей, затирающих работу друг друга.

Где наивная реализация ключа разваливается

Гонка в проверке

Последовательность «проверить наличие ключа, потом вставить» содержит зазор, в который помещаются оба одновременных повтора: обе стороны видят, что ключа нет, и обе выполняют работу. Резервировать ключ нужно атомарно, через уникальное ограничение базы, условную запись или транзакционный compare-and-set (атомарное сравнение с записью).

Это же относится и к примеру с платежом выше: замена словаря в памяти на Redis гонку не закрывает, пока проверка и вставка остаются двумя отдельными командами. Нужен атомарный примитив резервирования, вроде SET key value NX или INSERT ... ON CONFLICT DO NOTHING.

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

Слепок запроса, а не только ключ

Хранить один ключ недостаточно. Сервер канонизирует поля, определяющие бизнес-смысл операции, и считает от них хеш. Канонизация означает приведение к единому виду порядка полей, форматов чисел и дат, опущенных значений по умолчанию и незначащих пробелов. Если повторный вызов обязан воспроизвести решение, принятое по прежним правилам, в слепок включают ещё и версию политики. Пример: между первой попыткой и повтором поменялись тарифы, и повтор обязан вернуть старую цену, а не пересчитать по новой. Без версии в слепке сервер этого различия не увидит.

Когда тот же ключ приходит с другим слепком, это ошибка на стороне клиента, и отдавать ему старый результат нельзя. Разбор проектирования идемпотентных ручек предлагает отвечать 409 Conflict; автор практического руководства в этом случае возвращает 422. Важно, чтобы выбранный код был задокументирован и никогда не подменяется молчаливой отдачей чужого ответа.

Состояния и коды ответа

Минимальная модель состояний записи выглядит так: PROCESSING, SUCCEEDED, FAILED_RETRYABLE и FAILED_FINAL. Рядом хранятся ключ операции, слепок, отметки времени, идентификатор решения, снимок ответа и версия политики. Клиенту нужна детерминированная карта из состояния в код ответа:

• 201 или 200 — первый успешно завершённый результат.
• 200 с явной пометкой о повторе — проигрывание сохранённого ответа.
• 202 со ссылкой на статус — работу уже выполняет другой обработчик, начинать вторую не нужно.
• 409 — ключ переиспользован с другим содержимым.
• Задокументированная финальная ошибка — обработка провалилась, и автоматическое продолжение небезопасно.

Срок жизни ключей:
Хранить их вечно не нужно, это медленная утечка. Сутки покрывают практически любое реальное окно повторов, но выбирать срок стоит от риска предметной области: у платежей и у рекомендаций он разный. И помните, что ключ приходит снаружи: ограничьте длину и набор символов, привяжите его к арендатору и не дайте одному пользователю вытащить результат чужой операции.

Вторая половина задачи: база и очередь

Допустим, ручка стала идемпотентной. Остаётся более коварная проблема: почти всякая бизнес-операция пишет не в одно место. Заказ сохраняется в базу и публикует событие в очередь, чтобы склад начал сборку, почтовый сервис отправил подтверждение, а антифрод посмотрел на транзакцию.

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

Это две записи в две разные системы, и общей транзакции у них нет. Упал процесс, моргнула сеть, выкатился деплой между двумя вызовами — одна сторона зафиксирована, вторая нет. Заказ подтверждён на экране покупателя, а склад о нём не знает. Ошибка при этом нигде не залогирована и алерт не сработал.

Почему обернуть это в транзакцию нельзя

Соблазнительный и заведомо неверный вариант выглядит так:

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

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

Outbox: событие как строка в той же транзакции

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

Откатилась транзакция, и вместе с ней исчезла строка outbox: осиротевшего сообщения в очереди не осталось. Упало приложение сразу после фиксации — строка на месте со статусом pending, и доставщик заберёт её на следующем проходе. Паттерн опирается ровно на одну гарантию, которую база и так даёт: атомарность одной транзакции.

Доставщик выбирает пачку необработанных строк и помечает их отправленными только после подтверждения очередью. Ключевая деталь здесь одна:

Этот SELECT и последующая простановка статуса выполняются в одной транзакции: блокировка живёт до фиксации. Благодаря SKIP LOCKED доставщик масштабируется горизонтально из коробки, каждый экземпляр берёт свой набор строк. А если он упадёт посреди пачки, вся пачка откатится и уйдёт повторно, что даёт ещё один довод в пользу идемпотентного потребителя.

Может показаться, что здесь мы делаем ровно то, что осудили выше: держим блокировку на время сетевого вызова. Разница в том, что блокируется не бизнес-таблица и соединение берётся не из пула, обслуживающего пользовательские запросы, а SKIP LOCKED не даёт одной медленной строке задержать остальные.

Потребитель обязан быть идемпотентным

Если доставщик упал посреди прохода, на следующем он переотправит те же строки. Очереди вроде SQS и Kafka в типовой конфигурации гарантируют доставку «хотя бы один раз», поэтому дедупликация на приёмной стороне обязательна, и уникальным ключом служит идентификатор события или решения.

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

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

Что добавить перед продакшеном

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

Когда задержка опроса становится критичной, полагающийся на периодический опрос доставщик заменяют захватом изменений: инструменты вроде Debezium читают журнал предзаписи PostgreSQL и публикуют изменения без паузы на опрос. Таблица outbox и потребитель при этом не меняются. Но это заметно более тяжёлое эксплуатационное обязательство, поэтому начинать почти всегда стоит с опроса.

Что забрать с собой

Обе части задачи выглядят избыточными ровно до первого инцидента. Тридцать строк кода с ключом идемпотентности стоят дешевле одного тикета с заголовком «вы списали дважды», а таблица outbox дешевле расследования, почему заказ есть у клиента и отсутствует на складе.

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

Как одно неверное допущение о порядке вызовов обернулось эпидемией задвоенных операций, показано в разборе реального инцидента в финтех-системе.

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

Откройте самый денежный обработчик в своём сервисе и попробуйте отправить в него один и тот же запрос дважды. Если во второй раз что-то произошло, вы уже знаете, с чего начать понедельник.

Для тех, кто держит workspace на десятки пакетов, это ускорение pnpm install без изменений в конфигурации. Для пользователей Windows это ещё и конец .cmd и .ps1-обёрток: их заменяет .exe. Обратная сторона видна по патчу 12.3.1: обновление с 12.2 через self-update ломало миграцию старых shim, и это исправили в тот же день.

• Установка в больших workspace ускорена: lockfile читается во время discovery проектов, граф workspace обрабатывается один раз вместо полного копирования lockfile.
• Контекстно-зависимые глобальные команды и shim стали нативными исполняемыми файлами; в Windows .exe вместо .cmd и .ps1, старые shim мигрируют при следующей глобальной установке или self-update.
• Флаги доверия --trust-lockfile, --no-trust-lockfile, --trust-policy, --trust-policy-exclude и --trust-policy-ignore-after теперь работают и для remove и update.
• Исправлено зависание recursive run и exec, в том числе с --filter и --workspace-concurrency=1.
• Системный резолвер на Linux использует getaddrinfo и больше не должен молча обращаться к Google Public DNS при неподдерживаемой опции no_tld_query.

Откуда взялось ускорение в монорепозиториях

По заметкам к релизу, раньше pnpm сначала обходил все проекты workspace, а потом отдельно разбирал lockfile и копировал его целиком для резолвера. В 12.3 lockfile читается уже на этапе discovery, а граф workspace строится один раз и передаётся резолверу и генератору lockfile без полного копирования. Конкретных цифр ускорения команда pnpm в заметках не приводит, формулировка звучит как «sped up installs in large workspaces»; эффект тем заметнее, чем больше пакетов и чем толще lockfile.

Что изменилось для глобальных команд и Windows

pnpm умеет ставить node, deno и bun как глобальные команды, которые подбирают версию по контексту проекта. До 12.3 в Windows такие команды были скриптами .cmd и .ps1, а на других платформах shell-обёртками. Теперь везде это нативные исполняемые файлы. Старые shim от pnpm 12 мигрируют при следующей глобальной установке или self-update; именно этот переход и сломался при обновлении с 12.2, что исправили в 12.3.1: нативный shim теперь мигрирует при первом запуске.

Безопасность: trust-флаги и скрытие секретов

Механизм доверия к lockfile появился в pnpm 12 как защита от атак на цепочку поставок: пакеты, не прошедшие политику доверия, не ставятся. В 12.2 флаги были только у install и add; 12.3 добавляет их к remove и update. Второе изменение того же ряда: учётные данные и query-параметры из URL реестров теперь скрываются в сообщениях об ошибках fetch и загрузки tarball, так что токен приватного реестра больше не утекает в лог CI при обрыве соединения.

Исправления, которые стоит знать

• Добавление локальных директорий, tarball-файлов и tarball по URL через pnpm add снова работает.
• recursive run и recursive exec больше не зависают, включая варианты с --filter и --workspace-concurrency=1.
• Дочерние процессы в Windows запускаются корректно.
• Linux: системный резолвер переведён на getaddrinfo; при неподдерживаемой опции no_tld_query в resolv.conf pnpm больше не должен молча уходить к Google Public DNS, что важно в закрытых сетях и там, где внешние DNS фильтруются.
• 12.3.1: исправлены обработка workspace anchor и параллельная проверка lockfile.

Как обновиться

Обновляться стоит сразу на 12.3.1, минуя 12.3.0. Если pnpm установлен через Corepack или npm i -g pnpm, обновление идёт обычным способом; если через self-update, после перехода с 12.2 стоит один раз запустить любую глобальную команду, чтобы shim мигрировал. Проверить, что всё на месте: pnpm --version должен показать 12.3.1, а pnpm shim ls (если пользуетесь shim) не должен ругаться на старые обёртки.

Кому обновление ничего не изменит: одиночным проектам без workspace и тем, кто не пользуется глобальными командами pnpm. Из соседних новостей про инструменты JavaScript на сайте: GitHub CLI 2.99 и Wasmi 2.0. Полный список изменений с номерами issue лежит на странице релиза.

Источники: pnpm v12.3.0 на GitHub, pnpm v12.3.1 на GitHub

Изображение на обложке: pnpm, логотип проекта

Для разработчиков ИИ-приложений на TypeScript вывод простой: если в проекте есть пакет @prompty/core версии по 0.1.4 включительно или из ветки 2.0 с 2.0.0-alpha.1 по 2.0.0-beta.4 включительно, его нужно обновить, а файлы промптов из чужих репозиториев, от сообщества или сгенерированные моделью с этого момента считать кодом, а не конфигурацией. Исправления Microsoft выпустила в версиях 0.1.5 и 2.0.0-beta.5, говорится в advisory на GitHub.

• Уязвимость класса SSTI в TypeScript-runtime Prompty: шаблонизатор Nunjucks не ограничивал доступ шаблона к объектам JavaScript.
• Затронуты npm-пакет @prompty/core по 0.1.4 включительно и ветка 2.0 с 2.0.0-alpha.1 по 2.0.0-beta.4 включительно; исправлены 0.1.5 и 2.0.0-beta.5.
• CVSS 3.1: 10,0, вектор AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H; CWE-94 и CWE-1336.
• Эксплуатация требует, чтобы приложение обработало подготовленный злоумышленником файл .prompty; обычный запрос пользователя к модели код не выполняет.
• Advisory опубликовано 20 июля 2026 года, исправленные версии вышли в npm в тот же день; о находке Positive Technologies рассказала 2 сентября.

Как файл промпта превращался в код

Prompty хранит промпт в файле с YAML-заголовком и телом-шаблоном, а в TypeScript-runtime тело обрабатывает шаблонизатор Nunjucks. По описанию Microsoft в advisory, рендерер вычислял тело недоверенного шаблона «с неограниченным доступом к членам JavaScript-объектов» (перевод редакции): шаблон мог добраться до свойств constructor и prototype и через них выполнить произвольный код в процессе Node.js. Это классическая инъекция в серверные шаблоны, SSTI, только вместо HTML-шаблона здесь файл промпта.

Оценка 10,0 объясняется вектором: атака по сети, низкая сложность, без прав и без участия пользователя, с выходом за пределы уязвимого компонента и полной потерей конфиденциальности, целостности и доступности. На практике последствия зависят от того, с какими правами запущен процесс: Positive Technologies перечисляет доступ к данным приложения и секретам, изменение файлов и настроек, вмешательство в работу сервиса и полный отказ в обслуживании.

При этом речь не о том, что любой текстовый запрос пользователя к модели выполняет код на сервере, подчёркивают в Positive Technologies. Для эксплуатации приложение должно использовать уязвимый TypeScript-runtime с Nunjucks и обработать файл, который подготовил злоумышленник. Microsoft в advisory называет именно такие сценарии: файлы .prompty, полученные от сообщества, клонированные из чужих репозиториев или сгенерированные языковой моделью.

Что изменилось в исправленных версиях

По данным advisory, исправление вошло в pull request №404. Обновлённый рендерер приводит входные данные шаблона к «только собственным данным», отвергает обращение к constructor и prototype и запрещает вызов функций из шаблона. Обычная подстановка переменных, условия, циклы и вложенные свойства собственных данных продолжают работать, так что существующие промпты переписывать не придётся, если они не вызывали функции из тела шаблона.

В реестре npm версия 2.0.0-beta.5 появилась 20 июля 2026 года в 17:42 UTC, версия 0.1.5 в 18:54 UTC того же дня, а advisory Microsoft опубликовала в 18:55 UTC. На момент публикации тег latest в npm указывает на 0.1.6, тег alpha на 2.0.0-beta.5. В advisory затронутыми названы только npm-пакеты; про Python-пакет prompty и расширение для VS Code там ничего не сказано.

Что делать

Проверить, есть ли пакет в проекте и какой версии, можно командой npm ls @prompty/core. Если версия 0.1.4 или ниже, обновляйтесь до 0.1.5 или новее; если вы на ветке 2.0 (с 2.0.0-alpha.1 по 2.0.0-beta.4), до 2.0.0-beta.5 или новее. Microsoft в advisory просит обновиться до 2.0.0-beta.5 или выше.

Второй шаг не про версии. Старший специалист AppSec Research Positive Technologies Александр Халиков формулирует его так: «Файлы с промптами уже нельзя воспринимать как безобидные текстовые конфигурации. В современных ИИ-приложениях они могут содержать исполняемую логику и фактически становятся ещё одним элементом цепочки поставок программного обеспечения». Отсюда те же меры, что для кода: доверенные источники, контроль изменений и происхождения, запрет на обработку непроверенных шаблонов и запуск ИИ-инфраструктуры с минимально необходимыми правами. Если ваш агент сам генерирует или скачивает промпты и тут же их рендерит, это ровно тот сценарий, который Microsoft называет опасным.

Кто и как нашёл

Positive Technologies связывает находку с новой разработкой на основе ИИ, которая автоматизирует поиск уязвимостей и проверку возможности их эксплуатации; по словам компании, инженеру потребовалось две минуты на триаж результатов сканирования. Это заявление компании, независимо проверить его нельзя. В advisory на GitHub в графе «reporter» указан пользователь lexdotdev; между выпуском исправления в июле и публичным рассказом об исследовании в сентябре прошло полтора месяца.

Репозиторий microsoft/prompty на момент публикации собрал 1 255 звёзд на GitHub; Positive Technologies оценивает аудиторию экосистемы Prompty в «десятки тысяч разработчиков» по открытым данным npm, PyPI и Visual Studio Marketplace, и это тоже оценка компании. Нынешняя дыра в проекте не первая: в июне в том же репозитории уже выходили advisory о чтении файлов и выполнении JavaScript через frontmatter. Следующее, за чем стоит следить, это выход стабильной версии 2.0: ветка на GitHub пока помечена как alpha.

Источники: Positive Technologies: новое ИИ-решение помогло найти критическую уязвимость в проекте Microsoft, GitHub Advisory GHSA-w28w-gp39-m4p6, Репозиторий microsoft/prompty, Пакет @prompty/core в npm

Изображение на обложке: Логотип: Microsoft

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

• Каталог ~/.cache/codex-runtimes/codex-primary-runtime занимает 1,7 ГБ на macOS.
• Node.js 446,4 МБ, Python 440,6 МБ, LibreOffice headless 429,7 МБ, Poppler 187,9 МБ, Git 148,1 МБ; вместе нативные бинарники весят 771 МБ.
• В plugins/documents лежат skills, которые объясняют агенту, где искать бинарники и как ими пользоваться.
• Наблюдение сделано на одной машине с macOS; официальных данных о составе runtime на Windows и Linux нет.

Что именно лежит в каталоге

Уиллисон наткнулся на каталог случайно, разбирая ~/.cache/ утилитой OmniDiskSweeper. Внутри codex-runtimes/codex-primary-runtime три части: dependencies на 1,7 ГБ, plugins на 6,3 МБ и файл runtime.json на 4,1 КБ. В зависимостях четыре подкаталога: native на 771,0 МБ, node на 446,4 МБ, python на 440,6 МБ и bin на 28,7 КБ. В native лежат libreoffice-headless (429,7 МБ), poppler (187,9 МБ), git (148,1 МБ), libheif (4,7 МБ) и jxrlib (679,9 КБ).

Набор говорящий. Poppler читает и рендерит PDF, LibreOffice в headless-режиме конвертирует документы Word, Excel и PowerPoint в другие форматы без графического интерфейса, libheif открывает фотографии с iPhone в формате HEIC, jxrlib нужна для JPEG XR. Git и полноценные интерпретаторы Python и Node.js дают агенту возможность выполнять код и работать с репозиториями на машине пользователя.

Зачем агенту офисный пакет

Самое интересное в находке лежит в папке plugins/openai-primary-runtime/plugins/documents. По словам Уиллисона, в ней лежат skills, то есть текстовые инструкции, которые объясняют модели, как найти эти бинарники и как ими пользоваться. Это тот же подход, что в Claude Code и других агентных инструментах: вместо встроенного парсера каждого формата агент получает описание команды и вызывает готовую утилиту.

На практике это означает, что когда вы просите десктопный ChatGPT «сделать из этого документа PDF» или «вытащить таблицу из презентации», конвертация может выполняться локально, вызовом LibreOffice или Poppler из этого кэша. Это один из возможных путей: из наблюдения нельзя сказать, какие операции остаются локальными, а какие всё равно отправляют содержимое файла модели или обрабатываются иначе; документации OpenAI о составе runtime и о том, когда он скачивается, в открытом доступе нет.

Что стоит учесть

Наблюдение сделано на одной машине с macOS. Приложение для Windows может комплектоваться иначе, и переносить цифры на другие платформы не стоит. Не ясно и то, как обновляется runtime: отдельным скачиванием при первом обращении к документам или вместе с приложением.

Тем, кто следит за дисковым пространством, достаточно заглянуть в тот же путь. Удалять каталог вручную мы бы не советовали: что произойдёт с функциями работы с документами без него, автор не проверял, а официального способа отключить или очистить runtime OpenAI не описывает.

Разработчикам агентов здесь два практических наблюдения. Первое: в поставке для работы с форматами лежат полтора гигабайта проверенных открытых инструментов, включая LibreOffice, форк OpenOffice.org 2010 года. Второе: инструкции к этим инструментам лежат в виде читаемых файлов рядом с бинарниками, и их можно изучить как пример того, как крупный вендор пишет skills для своей модели.

Источники: Simon Willison: Codex bundles LibreOffice, OpenAI Help: Moving to the new ChatGPT desktop app

Изображение на обложке: Tproger

Разберём минимальный, но готовый к продакшену скелет: разделение слоёв, валидацию входных данных, централизованную обработку ошибок, версионирование, ограничение частоты запросов и автоматическую документацию. Все принципы применимы и к Express, и к Fastify, и к NestJS.

Чистое API — это прежде всего разделение ответственности: роутер знает маршруты, контроллер переводит HTTP в вызовы сервиса, сервис отвечает за бизнес-логику, а схема проверяет входные данные. Такой подход делает код предсказуемым при любом масштабе.

Чистое API — это, прежде всего, разделение ответственности: роутеры, контроллеры, сервисы и валидация живут в разных слоях.

Валидация с помощью Zod выполняется на границе — до того, как запрос попадёт в бизнес-логику.

Централизованный обработчик ошибок — единственное место, где исключения превращаются в HTTP-ответы.

Стоит закладывать версионирование и документацию OpenAPI с первого дня: позже это обойдётся дороже.

Fastify и NestJS дают те же архитектурные идеи из коробки, но логика слоёв от этого не меняется.

Что мы будем строить

Возьмём намеренно простой домен — каталог товаров. Нам важна не бизнес-логика, а структура. К концу у нас будет REST API с единым форматом ответов, валидацией, версионированием по пути /api/v1, ограничением частоты запросов и интерактивной документацией Swagger.

Структура проекта

Прежде чем писать код, договоримся, где что лежит. Каждая фича — отдельная папка, а не рассыпанный по проекту набор файлов.

• api/v1/ — все маршруты версионированы с первого дня. Добавить v2 позже можно новой папкой, а не рефакторингом.
• products/ — фичевая папка владеет роутером, контроллером, сервисом и схемой.
• middleware/ — сквозная функциональность: защита, логирование, лимиты.
• lib/ — утилиты без привязки к фреймворку.

Разделяем ответственность

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

Роутер знает только «куда идти»

Промежуточный обработчик валидации

Промежуточный обработчик validateRequest проверяет body, params и query до попадания в контроллер. Если данные не проходят проверку, ошибка передаётся в централизованный обработчик.

Контроллер переводит HTTP в вызовы сервиса

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

Сервис содержит бизнес-логику

Сервис не зависит от HTTP. Когда придёт время заменить хранилище в памяти на настоящую базу данных, потребуется поправить только этот файл.

Валидация на границе с Zod

Любое API, принимающее внешние данные, должно их проверять. Без валидации один некорректный запрос способен превратиться в ошибку времени выполнения, некорректную запись в базе или уязвимость.

Zod даёт две вещи сразу: проверку во время выполнения и типы TypeScript, выведенные из одной схемы. Промежуточный обработчик validateRequest проверяет body, params и query до того, как запрос попадёт в контроллер. Если данные невалидны, дальше они не идут.

Единый обработчик ошибок

Разбросанная обработка ошибок — один из главных источников хаоса: где-то возвращается { error: '...' }, где-то { message: '...' }, а где-то случайно отдаётся HTML-страница. Решение — один обработчик, через который проходят все исключения.

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

Единый формат ответов

Успешный ответ всегда выглядит как { success: true, data: ... }, а ошибка — как { success: false, error: { code, message, details } }. Фронтенд или сторонний интегратор знает, чего ожидать от любого эндпоинта.

Версионирование API

Версионировать API с первого дня стоит недорого. Добавить версию позже — значит ломать существующих клиентов или городить сложную миграцию.

Новая версия — новая папка src/api/v2/ и новый префикс. Старые клиенты продолжают работать на /api/v1.

Ограничение частоты запросов

Rate limiting защищает API от случайных и намеренных перегрузок. Настроить его в Express помогает пакет express-rate-limit.

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

Документация OpenAPI и Swagger

API без документации годится только для автора. С помощью swagger-jsdoc и swagger-ui-express можно получить интерактивную документацию прямо из JSDoc-комментариев в роутерах.

Совет:
Держите описания эндпоинтов в одном файле с маршрутами, а glob в swagger.ts настройте на файлы, доступные во время работы приложения. Лучше генерировать спецификацию на этапе сборки, чем полагаться на исходники TypeScript.

Fastify и NestJS: альтернативы Express

Всё, что мы разобрали, работает и в Express. Но если вы начинаете проект с нуля, стоит взглянуть на альтернативы.

• Fastify — быстрее Express в бенчмарках (порой в два раза), имеет встроенный логгер Pino и валидацию по схеме. Разделение слоёв остаётся на совести разработчика.
• NestJS — популярен в крупных компаниях: слои модулей, контроллеров и сервисов навязаны архитектурой, что упрощает введение новых разработчиков в проект.
• Express — остаётся лучшим выбором, если вы присоединяетесь к существующему проекту или команда уже знает экосистему.

Архитектурные принципы — разделение слоёв, единый формат ошибок, валидация на границе — не зависят от фреймворка. Меняется только синтаксис.

FAQ

Минимальный набор для старта

Для самостоятельного запуска понадобятся базовые зависимости и алиасы путей в tsconfig.json. Объявите @/* на папку src, и примеры заработают без ручных правок импортов.

Выводы

Чистая структура API — это не переусложнение. Это минимум, при котором бэкенд можно поддерживать нескольким людям.

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

Если начинаете новый Node.js-проект, не откладывайте структуру «на потом». А в существующем — попробуйте вынести валидацию в схему и собрать ошибки в одном обработчике. Потом всегда дороже.

Источники

Идеи и примеры в статье основаны на материале Gavin Cettolo «Clean API Design in Node.js: A Practical Guide» (dev.to).

Vite+ — бесплатный open-source CLI от VoidZero, объединяющий Vite, Vitest, Oxlint, Oxfmt, Rolldown, tsdown, Vite Task и менеджмент версий Node.js в одном инструменте.

Vite+ объединяет 7+ инструментов (Vite, Vitest, Oxlint, Oxfmt, Rolldown, Vite Task, vp env) под единым CLI-бинарником vp.

Требует Node.js 20.19+ или 22.12+. При более старой версии обновление обязательно.

Для новых Vite-проектов — удобен сразу. Для крупных production-кодовых баз с кастомными ESLint-плагинами — тестировать осторожно.

Единая точка конфигурации: vite.config.ts вместо .eslintrc, .prettierrc, vitest.config.ts и .nvmrc.

Команда vp check запускает форматирование, линтинг и проверку типов за один шаг.

Что входит в Vite+

Vite+ спроектирован так, чтобы один CLI заменил набор привычных команд. Вот что он консолидирует:

• Vite — дев-сервер и production-сборка через vp dev / vp build
• Rolldown — bundler следующего поколения, используемый Vite 8 вместо Rollup
• Oxlint — быстрый линтер для JS/TS, совместимый с большинством ESLint-правил
• Oxfmt — форматтер кода, заменяющий Prettier для большинства проектов
• Vitest — тесты, интегрированные с Vite-экосистемой
• Vite Task — запуск задач в монорепозитории с кэшированием (альтернатива Turborepo)
• vp env — управление версиями Node.js без NVM или FNM

Ключевое преимущество — не только скорость, но и согласованность: меньше конфиг-файлов, меньше точек, в которых что-то может разъехаться.

Когда Vite+ имеет смысл

Vite+ подходит не для каждой ситуации. Вот ориентир:

• Используйте, если начинаете новый Vite-проект — меньше конфигурации с самого старта
• Используйте, если хотите единую команду для форматирования, линтинга и проверки типов
• Используйте, если нужно pin-нуть Node.js-версию в проекте без NVM/FNM
• Осторожно, если production-кодовая база зависит от нишевых ESLint-плагинов или кастомных правил
• Осторожно, если в монорепозитории уже настроен Turborepo или Nx
• Осторожно, если поведение Prettier жёстко зафиксировано и команда не готова к разнице в форматировании

Что нужно для начала

Важная версионная оговорка: Vite 8 требует Node.js 20.19+ или 22.12+. Если на машине установлена более старая версия — обновите перед установкой Vite+.

Для работы с этим гайдом понадобится:

• Node.js 20.19+ или 22.12+
• Базовое знакомство с командной строкой
• Терминал на macOS, Linux или Windows
• Существующий Vite-проект, если хотите протестировать миграцию

ESLint, Prettier, Vitest, NVM или FNM глобально устанавливать не нужно — Vite+ берёт это на себя.

Установка Vite+

Vite+ устанавливается как единый бинарник vp. На macOS или Linux: Официальный сайт проекта: vite.plus.

На Windows в PowerShell:

После установки перезапустите терминал и проверьте CLI:

Создание проекта

Для создания нового проекта используется команда vp create. Интерактивные подсказки предложат выбрать фреймворк, шаблон и пакетный менеджер:

После создания проекта переходим в директорию и запускаем дев-сервер:

Команда vp dev делает то же, что npm run dev, pnpm dev или yarn dev — только теперь команда единая для всей команды, независимо от пакетного менеджера.

Конфигурация в vite.config.ts

Вся конфигурация Vite+ собирается в одном файле — vite.config.ts. Вместо разбросанных .eslintrc, .prettierrc, vitest.config.ts и .nvmrc — один типизированный файл. Базовая конфигурация выглядит так:

Форматирование с Oxfmt

Добавьте секцию fmt для настройки форматирования:

Запуск форматирования: vp fmt. Для большинства проектов Oxfmt заменяет Prettier — но перед миграцией production-кодовой базы прогоните его на отдельной ветке и проверьте diff: Oxfmt может форматировать иначе в отдельных случаях.

Линтинг с Oxlint

Oxlint работает быстро и поддерживает большинство ESLint-совместимых правил. Главное ограничение — совместимость плагинов. Если проект зависит от нишевых ESLint-плагинов или кастомных правил, перед полной заменой ESLint нужна тщательная проверка.

Тесты с Vitest

Запуск тестов: vp test. Vitest хорошо интегрируется с Vite-экосистемой и переиспользует ту же ментальную модель и инструментарий.

Единая проверка с vp check

После настройки форматирования, линтинга и тестов — запустите единую проверку качества:

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

Vite+ сообщит о проблеме в терминале. Для автоматического исправления того, что можно исправить автоматически:

Важная оговорка: --fix не чинит всё подряд. Форматирование и часть lint-проблем — да, ошибки типов и логические баги — нет. Это инструмент автоисправления, а не замена ревью кода.

Проверка staged-файлов перед коммитом

В традиционном стеке для pre-commit проверок используют Husky и lint-staged. Vite+ консолидирует часть этого рабочего процесса через конфигурацию staged:

Vite+ предоставляет команду и конфигурацию staged-файлов — git hook при этом нужно настроить самостоятельно (Vite+ не делает это автоматически). После настройки это предотвращает попадание проблем с форматированием и типами в основную ветку.

Миграция существующего Vite-проекта

Для уже существующего Vite-проекта есть команда миграции:

Она переносит конфигурацию Oxlint, Oxfmt и lint-staged в vite.config.ts. Важно: не воспринимайте это как финальный шаг. Миграция — начало ревью, а не конец. Рекомендуемый порядок:

1. Запустить vp migrate
2. Запустить vp check
3. Проверить изменения через git diff
4. Просмотреть сгенерированный конфиг, изменения в package.json и diff форматирования
5. Только после ревью — мёржить

Управление версиями Node.js через vp env

Vite+ включает менеджмент версий Node.js через vp env. Зафиксировать конкретную версию для проекта:

Это гарантирует одинаковую версию рантайма у всех разработчиков и снижает риск environment-специфичных багов, особенно когда требования Vite к Node.js меняются между мажорными версиями. Можно заменить .nvmrc или FNM для команд, хотящих управлять всем через Vite+.

Vite+ против традиционного инструментария

Вот как Vite+ соотносится с привычным стеком по ключевым задачам:

• Дев-сервер: npm run dev → vp dev
• Production-сборка: Vite + Rollup-конфиг → vp build
• Форматирование: Prettier + .prettierrc → Oxfmt через vite.config.ts
• Линтинг: ESLint + конфиг плагинов → Oxlint через vite.config.ts
• Тесты: отдельный vitest.config.ts → vp test
• Проверка качества: несколько package.json-скриптов → vp check
• Версия Node.js: .nvmrc или FNM → vp env pin
• Staged-проверки: Husky + lint-staged → staged-конфиг Vite+ с ручной настройкой hook'а
• Задачи монорепозитория: Turborepo/Nx → vp run через Vite Task

Текущие ограничения

Vite+ перспективен, но не является универсальной заменой для всех JavaScript-проектов. Перед широким внедрением важно учесть:

• Зрелость экосистемы — Vite+ новее инструментов, которые он консолидирует
• Совместимость ESLint — Oxlint поддерживает большинство правил, но не каждый плагин и кастомное правило
• Форматирование — Oxfmt может давать не полностью идентичный Prettier вывод в отдельных случаях
• Фреймворк-специфичность — Vite+ наиболее силён в Vite-экосистеме; framework-специфичное поведение нужно тестировать
• Размер установки — Vite 8 тяжелее Vite 7 из-за lightningcss и Rolldown
• Изменения рабочего процесса — замена привычных скриптов на vp требует документирования и адаптации команды

Vite+ — не волшебная замена каждого JavaScript-инструмента. Это серьёзная попытка сократить фрагментацию frontend-инструментария, сделав Vite точкой входа в более интегрированный рабочий процесс разработки.

Выводы

Vite+ делает практическую ставку: JavaScript-инструментарий легче поддерживать, когда бандлер, линтер, форматтер, тест-ранер, task runner и менеджер рантайма спроектированы работать вместе. Для новых Vite-проектов это сразу даёт меньше конфиг-файлов, меньшую поверхность команд и единый vp check для стандартных проверок.

Для крупных production-приложений лучший подход — постепенное внедрение: протестировать на ветке, проверить diff форматирования, убедиться в покрытии линтинга, проверить поведение CI. Инструмент не ставит точку в эволюции frontend-инструментария — он указывает направление: меньше фрагментации, больше интеграции.

Источник: Vite+ guide: One CLI for JavaScript tooling — LogRocket Blog, Emmanuel John, 12 мая 2026 г. Репозиторий Vite+: github.com/voidzero-dev/vite-plus.

1. Как я утонул в генерациях
2. Экзамен вместо «прыжков» по сервисам
3. Небольшой технический конвейер
4. Зачем цифры важнее впечатлений
5. Простой тест на форматы
6. Как ведут себя Riverflow, Flux и Seedream
7. Отчёты, артефакты и спокойная аналитика
8. Сценарий «восемь формулировок»
9. Зрелый подход к выбору AI

В прошлой статье я рассказывал, как собрал тестовый стенд для AI‑генерации. Теперь — про то, как превратил его в живой процесс с разными сценариями и метриками.

1. Как я утонул в генерациях

Я осознал что в очередной раз листал чат и не мог найти тот самый удачный вариант обложки.

Ситуация повторялась по одному и тому же шаблону. Запускаю один сервис — получаю результат, морщу лицо и сразу иду в другой. Там промпт приходится переформулировать: движок по-другому читает слова. В третьем генераторе наконец складывается приятная композиция, но детализация рушит весь смысл. Через пару дней на диске лежит россыпь PNG, а я уже не понимаю, где оказался осознанный успех, а где просто повезло. В какой-то момент я сказал себе: стоп. Случайные «попробую тут, попробую там» не ведут никуда.

2. Экзамен вместо «прыжков» по сервисам

Тогда я придумал простое правило. Любой сервис, который претендует на место в моём рабочем наборе, должен пройти экзамен. Не приятную беседу с общими вопросами, а одинаковый для всех, жёсткий сценарий. Без исключений и любимчиков.

3. Небольшой технический конвейер

Реализация получилась до обидного простой. Node.js, TypeScript, запуск через tsx. Список моделей вынесен в отдельный конфиг, API-ключ лежит в .env, а команды запуска выглядят вроде npm run test:niche или npm run test:collage-2x2-eight-prompts. Я взял творческий хаос и сложил его в аккуратный pipeline.

Дальше всё происходит автоматически: запускаешь тест — и один и тот же набор задач последовательно проходит через всех кандидатов. Мой вклад заканчивается на нажатии Enter.

4. Зачем цифры важнее впечатлений

Зачем вообще так усложнять? Потому что мантра «любая нейросеть — она и есть нейросеть» на практике не работает. Разброс колоссальный. Один сервис очень аккуратно держит геометрию кадра, но мелкие детали превращает в мыло. Другой рисует фактуру так, что хочется печатать и вешать, но при запросе «коллаж 3×3 с чёткими границами» внезапно решает творчески переосмыслить сетку. Третий стабильно отвечает и по времени, и по предсказуемости, но на сотне запросов выписывает такой чек, что хочется закрыть вкладку.

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

5. Простой тест на форматы

Возьмём самый базовый пример — проверка соотношения сторон. Формулировка элементарная: закат над горами, три варианта — 3:4, 1:1 и 16:9. Казалось бы, минимальный уровень адекватности. Но нет.

Достаточно пробежать глазами столбец со статусом. Три запроса — три быстрых проверки «на глаз». Там, где на 3:4 и 16:9 горит FAIL, модель откровенно игнорирует задачу и рисует квадрат или удобный для себя формат. И это при том, что промпт простейший: не сложная сцена, не коллаж — всего лишь «закат, горы и нужная рамка».

6. Как ведут себя Riverflow, Flux и Seedream

Если посмотреть на результаты, riverflow-v2-pro аккуратно соблюдает все три формата. Но за эту аккуратность приходится платить временем: портретная картинка генерируется около 360 секунд. Шесть минут — роскошь, если у вас в руках горящий дедлайн. Упрощённая версия, riverflow-v2-fast, выдаёт правильные форматы за секунды и остаётся в адекватных рамках по времени — это уже инструмент для реальных задач.runware+2

С моделями Flux история другая. Почти вся линейка black-forest-labs стабильно промахивается по нестандартным форматам: колонка «Соотношение» упорно показывает 4/3 или 1/1, хотя в запросе чётко указано «16:9, wide landscape». Относительно ровно ведёт себя только flux.2-max, который хотя бы честно выдаёт квадрат, но проблемы с другими соотношениями никуда не деваются.github+1

Seedream-4.5 от Bytedance, напротив, поражает скоростью: ответы прилетают за 7–8 секунд, но модель регулярно игнорирует заданный формат и возвращает квадрат 2048×2048. Для макета, привязанного к конкретным пропорциям — сторис, постера или баннера — такая «быстрота» только ломает всю вёрстку.eachlabs+1

7. Отчёты, артефакты и спокойная аналитика

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

Особенно сильно это помогает в задачах, где критична композиция: нужна ровная сетка 2×2 или 3×3 без самодеятельности в духе «я тут чуть подвину, так красивее». Это как раз те случаи, когда от сервиса нужна дисциплина, а не внезапные художественные «инициативы».

8. Сценарий «восемь формулировок»

Отдельный пласт наблюдений даёт сценарий «восемь формулировок» (collage-2x2-eight-prompts). Суть задачи не меняется, контент остаётся одним и тем же. Я варьирую только подачу: где-то пишу запрос грубо и коротко, где-то — щадяще и структурно, местами добавляю лишний контекст.

На этом месте становится видно, как модель реагирует не на саму тему, а на стиль запроса. Одна и та же нейросеть спокойно выдерживает строгое техническое ТЗ и проваливается при формулировке «сделай красиво, сам понимаешь». После таких тестов по-другому относишься к промптам: начинаешь формулировать точнее, понимая, какая модель как «слушает» текст. И внезапно исчезают загадки в духе «почему здесь получилось, а там всё развалилось».

9. Зрелый подход к выбору AI

Главный вывод из всей этой истории довольно приземлённый. Выбирать AI-сервисы по рекламе, по восторженным постам в Telegram или по одному удачному демо-кадру — путь к разочарованию. Их нужно ставить в одинаковые условия. Прогонять по своим реальным задачам, а не по чужим презентациям. Сохранять результаты и сравнивать их по конкретным цифрам.

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

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

Denwer SE решает все эти проблемы, оставаясь при этом таким же портативным — достаточно скопировать папку на флешку или в облачный каталог.

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

Самое болезненное место при локальной разработке это самоподписанные сертификаты. Браузеры постоянно ругаются, приходится кликать «Принять риск». Для командной разработки это вообще катастрофа: каждый участник должен сгенерировать свой сертификат и добавить в исключения.

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

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

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

Исходники панели управления не открыты (распространяется скомпилированный EXE), но архитектура и конфиги полностью прозрачны. В планах — добавить поддержку Nginx в качестве альтернативы. Следите за обновлениями.

Ниже — перевод статьи Уиллисона: что такое LiteParse, почему его удалось перенести в браузер и как выглядит вайб-кодинг, когда автор не читает ни строчки из получившегося HTML и TypeScript.

LiteParse от LlamaIndex — классический PDF-парсинг без ИИ. Эвристики spatial text parsing вычисляют порядок чтения (колонки, подписи, сноски), а Tesseract OCR добирает сканы.

Браузерная версия собрана из тех же PDF.js и Tesseract.js — никакого сервера, данные остаются на устройстве.

Процесс: план в plan.md, команда «build it», очередь follow-up-промтов, Playwright + red/green TDD, деплой на GitHub Pages через Actions.

Время в Claude Code на фазу сборки — 59 минут. Уиллисон не прочитал ни одной строки получившегося кода.

Уиллисон готов привязать к проекту репутацию — редкий случай для его вайб-проектов. Статический сайт и полная приватность делают blast radius почти нулевым.

Что такое LiteParse и зачем он нужен

LlamaIndex выложили опенсорс-инструмент LiteParse — Node.js CLI для извлечения текста из PDF. Что приятно: LiteParse не использует ИИ-модели. Это старый добрый PDF-парсинг с фолбеком на Tesseract OCR (или другой подключаемый OCR-движок) для файлов, где «текст» представлен картинками страниц, а не самим текстом.

Сложная задача, которую решает LiteParse, — выдать текст в нормальном порядке, несмотря на причудливые макеты PDF. Авторы называют это «spatial text parsing», пространственным парсингом: хитрые эвристики распознают многоколоночную вёрстку и группируют блоки так, чтобы текст читался линейно.

В документации LiteParse описан паттерн Visual Citations with Bounding Boxes — «визуальные цитаты с ограничивающими рамками». Уиллисону идея нравится: отвечать на вопросы по PDF и прикладывать к ответу обрезанный и подсвеченный фрагмент исходника — хороший способ поднять доверие к ответам RAG-системы (retrieval-augmented generation — когда LLM отвечает, подтягивая нужные куски из базы документов).

LiteParse задуман как CLI для агентов. Запускается вот так:

Уиллисон попробовал инструмент с Claude и быстро понял: оставаться CLI-приложением LiteParse вовсе не обязан. Он построен на PDF.js и Tesseract.js — двух библиотеках, с которыми автор уже делал похожие штуки в браузере. Единственная причина, почему у LiteParse до сих пор не было чистой браузерной версии, — её просто никто не сделал.

Знакомство: LiteParse в браузере

Зайдите на simonw.github.io/liteparse/ и попробуйте инструмент на любом PDF — всё работает прямо в вашем браузере. Интерфейс минимальный: перетаскиваете файл, выбираете режим (с OCR или без), на выходе получаете распознанный текст и pretty-printed JSON, оба с кнопкой Copy. Опционально можно вывести превью всех страниц PDF.

Как это собрали с Claude Code и Opus 4.7

Всё началось в обычном приложении Claude на iPhone. Уиллисон хотел пощупать LiteParse и загрузил с телефона случайный PDF с таким промтом:

Clone https://github.com/run-llama/liteparse and try it against this file

Обычный Claude теперь умеет клонировать репозитории прямо с GitHub и ставить пакеты из PyPI и npm — даже без доступа к остальному интернету из контейнера. Уиллисон часто так пробует новый опенсорс с телефона, не доставая ноутбук. После нескольких уточняющих вопросов (весь диалог можно открыть в расшаренном транскрипте) он спросил главное:

Does this library run in a browser? Could it?

Ответ был достаточно убедительным, чтобы попробовать всерьёз. Уиллисон открыл ноутбук, переключился на Claude Code. Форкнул оригинальный репозиторий на GitHub, склонировал локальную копию, создал новую ветку web и скопировал последний ответ Claude в файл notes.md. А потом сказал Claude Code:

Get this working as a web app. index.html, when loaded, should render an app that lets users open a PDF in their browser and select OCR or non-OCR mode and have this run. Read notes.md for initial research on this problem, then write out plan.md with your detailed implementation plan

Подобные проекты Уиллисон всегда начинает с плана. Иногда он включает у Claude «режим планирования», но здесь ему нужен был план как артефакт в репозитории — поэтому сразу plan.md. Это позволяет итеративно править сам план. Заметив, что Claude решил отложить «canvas-encode swap» (замену способа, которым PDF.js сохраняет страницы картинкой — без неё не работает превью страниц в браузерной версии) на v2, Уиллисон дописал:

Update the plan to say we WILL do the canvas-encode swap so the screenshots thing works

Через несколько коротких правок получился plan.md, который автор счёл достаточно хорошим для реализации. И сказал:

build it.

И дальше Уиллисон по большей части оставил Claude Code работать самому: возился с другими проектами, периодически заглядывал проверить прогресс. Параллельно подбрасывал подсказки в очередь. Queued-prompts не попадают в стандартный экспорт транскрипта Claude Code, но их можно вытащить из папки ~/.claude/projects/ командой rg queue-operation --no-filename | grep enqueue | jq -r '.content'. Ниже — выдержка из этих follow-up-промтов с авторскими комментариями:

• «Реализуй через Playwright и red/green TDD, спланируй это тоже» — подробнее про red/green TDD Уиллисон писал отдельно
• «Давай использовать собственный рендерер PDF.js» — Claude начал экспериментировать с pdfium
• «Финальный UI должен показывать и текст, и pretty-printed JSON — оба в textarea с кнопками копирования. И должен быть mobile-friendly» — новая идея, как UI должен выглядеть
• «Делай маленькие коммиты по ходу дела» — см. ниже
• «В index.html вверху страницы добавь ссылку на github.com/run-llama/liteparse» — важно кредитить зависимости
• «View on GitHub → — плохая формулировка: это репозиторий не браузерной обёртки, а базовой библиотеки LiteParse»
• «Чекбокс Run OCR должен быть снят по умолчанию»
• «Когда пытаюсь распарсить PDF в браузере — вижу Parse failed: undefined is not a function» — Claude тестировал в Playwright под Chrome, а оказалось, что это баг Safari
• «Когда нажимают Copy, пусть текст на 1,5 секунды меняется на Copied!»
• «Оформи поле выбора файла так, чтобы длинные имена не ломали вёрстку в Firefox. И добавь drag-and-drop-зону, которая ещё и кликабельна» — скриншоты мелких UI-глитчей Claude воспринимает на удивление хорошо
• «Текст в drop-зоне сейчас чуть ближе к верху — поцентруй по вертикали» — точечная правка поверх предыдущей
• «В Safari на macOS всё ещё падает с readableStream» — Claude починил, как только ему подсказали запустить Playwright в этом браузере; следующим промтом Уиллисон подтвердил: «works in safari now»

«Делай маленькие коммиты» Уиллисон теперь просит по привычке: это упрощает последующее чтение и ревью кода, а ещё, по его непроверенной гипотезе, помогает агенту работать эффективнее — дополнительный стимул планировать и брать задачи по одной.

Пока агент работал, Уиллисон решил, что было бы неплохо уже повзаимодействовать с ещё не завершённой версией. Он открыл отдельную сессию Claude Code в той же папке и спросил, как запустить сборку. Ответ — npx vite: команда поднимает dev-сервер с live-reload, так что каждая правка на диске сразу видна в браузере, и можно тут же просить «подкрути вот это».

Ближе к концу Уиллисон решил, что проект достаточно хорош для публикации. Новая сессия Claude Code, промт:

Look at the web/ folder - set up GitHub actions for this repo such that any push runs the tests, and if the tests pass it then does a GitHub Pages deploy of the built vite app such that the web/index.html page is the index.html page for the thing that is deployed and it works on GitHub Pages

После нескольких итераций получился рабочий GitHub Actions workflow, который собирает приложение через Vite и деплоит результат на simonw.github.io/liteparse/. GitHub Pages Уиллисон любит именно за такие кейсы: любой репозиторий бесплатно превращается в задеплоенное веб-приложение с произвольным build-шагом — и всё это настраивает Claude.

В проектах такого типа всегда есть риск, что модель «сжульничает»: пометит ключевые фичи как TODO и сделает их заглушками или срежет углы в требованиях. Ответственный способ это поймать — прочитать весь код. Но здесь это не планировалось, поэтому Уиллисон запустил OpenAI Codex с GPT-5.5 (у автора был ранний доступ к модели) и попросил:

Describe the difference between how the node.js CLI tool runs and how the web/ version runs

Ответ был достаточно подробным, чтобы убедиться: Claude не срезал углы в чём-то критичном. Суммарное время в Claude Code на фазу «build it» — 59 минут. Полный транскрипт сессии Уиллисон потом экспортировал своим же инструментом claude-code-transcripts — правда, без очереди follow-up-промтов, их экспорт пока не подхватывает.

Это ещё вайб-кодинг или уже нет?

Уиллисон педантичен в определении vibe coding: это не любое использование ИИ для написания кода. Вайб-кодинг — это когда вы используете ИИ и при этом вообще не просматриваете получившийся код и не думаете о нём. По собственному определению автора, LiteParse for the web — пожалуй, максимально чистый вайб-кодинг: ни одной строки HTML и TypeScript Уиллисон не прочитал (и, пока писал это предложение, даже полез проверять, JS там или TS).

И всё же этот проект не ощущается как другие его вайб-проекты:

• Это статическое браузерное приложение на GitHub Pages. Blast radius (радиус поражения от бага) почти нулевой: для конкретного PDF оно или работает, или нет.
• Приватные данные никуда не уходят — вся обработка в браузере, поэтому аудит безопасности не нужен. Уиллисон специально заглянул в network-панель и убедился: при парсинге PDF дополнительных запросов нет.
• Инженерный опыт всё равно потребовался — чтобы сообразить, что перенос LiteParse в браузер вообще возможен. Без этого никакой агент не справился бы.

Главное — Уиллисон готов привязать к этому проекту свою репутацию и рекомендовать его другим. В отличие от большинства его вайб-проектов, он не уверен, что дополнительные инженерные часы заметно улучшили бы первый релиз. «Оно работает как есть, и это нормально».

PR в апстрим Уиллисон не открывал — не обсуждал это с командой LiteParse. Но завёл issue: если команде будет интересно взять вайб-код как отправную точку для чего-то более официального — пусть забирают.

Выводы

LiteParse for the web — не прорыв, а аккуратная обёртка поверх PDF.js и Tesseract.js. Но с конкретной пользой: приватный парсинг PDF без облака, который можно забрать и поставить у себя.

Главное в кейсе — не сама браузерная обёртка, а рабочий паттерн: план-артефакт в репозитории, запуск через «build it», очередь follow-up-подсказок поверх работающего агента и финальная проверка результата другой моделью. Такой процесс повторяется на любом проекте сопоставимой сложности.

Оригинал: Extract PDF text in your browser with LiteParse for the web Simon Willison, 23 апреля 2026 года. Апстрим-репозиторий LiteParse — github.com/run-llama/liteparse, демо браузерной версии — simonw.github.io/liteparse/.

• Скомпрометирована одна npm-версия @bitwarden/cli@2026.4.0. Окно атаки — 1 час 33 минуты 22 апреля 2026 года.
• Vault-данные пользователей Bitwarden не затронуты. Пострадал только npm-канал доставки CLI и те, кто успел поставить эту сборку.
• Вектор — скомпрометированный action checkmarx/ast-github-action, который Bitwarden подтягивал в свой CI. По словам исследователей, это первый зафиксированный взлом пакета через npm trusted publishing.
• Малварь таргетит ИИ-ассистенты Claude, Cursor, Codex CLI, Aider и AWS-based Kiro — отдельный модуль собирает их конфиги и API-ключи.
• Если ставили — ротируйте npm/GitHub-токены, SSH-ключи и облачные креденшлы AWS/Azure/GCP; проверьте CI/CD-пайплайны и публичные репозитории со строкой «Shai-Hulud» в имени.

Что случилось с пакетом

По данным The Hacker News, в ночь с 22 на 23 апреля 2026 года в npm-реестре появилась версия @bitwarden/cli@2026.4.0 с дополнительным файлом bw1.js внутри. Сборка была доступна 1 час 33 минуты — с 17:57 до 19:30 по времени Нью-Йорка, — после чего её сняли с публикации. Первыми на неё обратили внимание исследователи Socket, JFrog и OX Security. JFrog описал поведение как «кражу GitHub/npm-токенов, содержимого .ssh, .env, истории shell, секретов GitHub Actions и облачных провайдеров с выгрузкой на внешние домены и в виде коммитов в GitHub».

Bitwarden подтвердил инцидент и уточнил, что «расследование не обнаружило признаков доступа к данным пользовательских хранилищ и компрометации продакшн-систем». По словам компании, доступ нарушителя был отозван, вредоносный релиз помечен как deprecated, по версии 2026.4.0 заводится отдельный CVE. Пострадавшие — только те, кто успел скачать пакет в полуторачасовом окне и выполнил его установку.

Как устроен троян

Механика по отчёту Socket проста, но многоступенчата. В package.json зловредной версии добавлен preinstall-хук, который запускает скрипт bw_setup.js. Тот проверяет наличие Bun — альтернативного JS-рантайма — и, если его нет, скачивает. Затем Bun-ом запускается обфусцированный загрузчик bw1.js. Bun тащат с собой не случайно: на машине жертвы его, скорее всего, нет, а корпоративный EDR (антивирус нового поколения для рабочих станций и серверов) реагирует на неожиданный бинарник хуже, чем на стандартный npm-скрипт. Preinstall-хук при этом срабатывает ещё до того, как код пакета формально «установлен».

• npm- и GitHub-токены из локальных конфигов и переменных окружения;
• приватные SSH-ключи из ~/.ssh;
• содержимое .env-файлов и историю shell (.bash_history, .zsh_history);
• секреты GitHub Actions из переменных окружения CI;
• креденшлы облачных провайдеров — AWS, Azure, Google Cloud;
• конфиги и API-ключи ИИ-ассистентов Claude, Cursor, Codex CLI, Aider и AWS-based Kiro.

Собранные данные шифруются AES-256-GCM и выгружаются двумя каналами. Основной — POST на домен audit.checkmarx[.]cx (конкретно путь /v1/telemetry), который притворяется инфраструктурой Checkmarx. Резервный — малварь создаёт публичные GitHub-репозитории в аккаунте жертвы и кладёт туда зашифрованный payload. В названиях репозиториев встречается строка «Shai-Hulud: The Third Coming» — отсылка к прошлогодней одноимённой кампании в npm. OX Security подчёркивает, что такой тайник (по терминологии безопасников — dead-drop) через GitHub опасен отдельно: утёкшие секреты становятся доступны любому, кто ищет по публичным репозиториям, — а системы защиты почти не следят за исходящим трафиком в GitHub.

Поверх этого в бинарнике есть модуль-червь: с украденным npm-токеном малварь находит все пакеты, которые жертва имеет право публиковать, и вбрасывает в них тот же payload. Endor Labs называет его «CanisterSprawl» и считает один из самых полных npm supply chain-пейлоадов на сегодняшний день: шесть разных поверхностей для сбора секретов, OIDC- и cloud-кража, самораспространение через npm-публикации и отдельный модуль для ИИ-ассистентов.

Отдельный удар по ИИ-ассистентам

Отдельный модуль малвари специально ищет артефакты ИИ-кодеров — API-ключи OpenAI и Anthropic из конфигов Claude, Cursor и Codex CLI, токены Aider, настройки AWS-based Kiro. Endor Labs считает, что это один из первых публично задокументированных случаев, когда supply chain-атака отдельной веткой целится на «кошельки разработчиков у ИИ». Ключ к Anthropic или OpenAI — это не только деньги на балансе аккаунта жертвы, но и возможность с его помощью заставить ИИ-ассистента писать закладки в код при следующих авто-запросах.

Почему малварь пропускает русскую локаль

Малварь завершается без выполнения, если в системе выставлена русская локаль. Socket отмечает три возможных причины: отдельный оператор, использующий общую инфраструктуру, отколовшаяся группа с идеологическими мотивами или эволюция самой кампании. На практике для российских разработчиков это не даёт защиты: большинство dev-машин, серверов и CI-раннеров работают с англоязычной локалью по умолчанию (обычно en_US.UTF-8), поэтому пропуск по локали чаще всего не срабатывает.

Что делать, если могли установить 2026.4.0

• Сначала убедитесь, что пакет действительно попал в ваши машины и раннеры: прогрепайте package-lock.json, pnpm-lock.yaml и yarn.lock на @bitwarden/cli версии 2026.4.0, посмотрите логи npm-установок в ночь на 23 апреля МСК.
• Ротируйте все токены с этих машин: npm-токены, GitHub PAT (включая fine-grained), SSH-ключи, AWS access/secret keys и STS-сессии, Azure SP, GCP service accounts.
• Замените секреты в GitHub Actions и других CI-системах, где пакет мог запускаться, — включая secrets, variables и OIDC-конфигурации.
• Пройдитесь по API-ключам ИИ-ассистентов (Anthropic, OpenAI, Cursor, Aider) и отзовите их в кабинетах провайдеров; сверьте биллинг на предмет аномальных трат.
• Проверьте публичные репозитории в своём GitHub-аккаунте: ищите имена в формате <слово>-<слово>-<3 цифры> (например, fremen-muaddib-042) со строкой «Shai-Hulud» в README и удалите.
• Откатитесь на безопасную версию CLI — 2026.3.x или актуальную стабильную, которую Bitwarden опубликовал после инцидента. Ставьте её через npm i @bitwarden/cli@<версия>, а не через latest или диапазон.

Связь с Checkmarx и первый взлом через npm trusted publishing

Накануне, 21 апреля, Checkmarx раскрыла собственный инцидент — компрометацию KICS Docker-образов, GitHub-расширений и пакета checkmarx/ast-github-action, который используется во многих CI-пайплайнах. По данным Endor Labs, репозиторий Bitwarden подтягивал именно этот action, и через него злоумышленники получили доступ к npm-каналу. Socket приводит прямые пересечения: тот же домен audit.checkmarx[.]cx, тот же паттерн обфускации __decodeScrambled с seed-значением 0x3039 — технический отпечаток, указывающий на одних и тех же авторов, — плюс тот же приём «украсть → выгрузить в GitHub → распространиться дальше».

Исследователь Аднан Хан утверждает, что это первый зафиксированный случай компрометации пакета, использующего npm trusted publishing — механизм OIDC-публикации, при котором GitHub Actions обменивается на короткоживущий npm-токен без долгоживущих секретов в CI. Его как раз продвигали в ответ на регулярные утечки npm-токенов у мейнтейнеров. На деле trusted publishing оказался не панацеей: если нарушитель получает доступ к GitHub Actions-воркфлоу с правом публиковать пакет, OIDC-токен ему выдаёт сам npm. Атрибуция у исследователей — группа TeamPCP, уже засветившаяся на взломах LiteLLM и Trivy. Аккаунт TeamPCP в X на момент выхода материала заблокирован.

Выводы для npm-экосистемы и supply chain

Случай укладывается в серию ударов по цепочке доставки последних двух недель: Trivy и LiteLLM на PyPI, Axios и PyPI, теперь Checkmarx и Bitwarden. Характерная деталь — защитный слой не спасает: trusted publishing, OIDC и короткоживущие токены не помогают, если злоумышленник уже получил доступ к CI-воркфлоу. Практический вывод: pin-версии в лок-файлах, отдельный CI-аккаунт с минимальными правами, еженедельная ревизия CI-секретов и мониторинг собственного GitHub на появление незнакомых публичных репозиториев. Инвентаризация секретов, которые ходят через CI/CD, перестала быть теоретическим упражнением.

Файл .gitignore — один из первых, который появляется в любом репозитории. Но многие добавляют его по привычке, не разбираясь в синтаксисе и не думая о глобальных настройках. В итоге в историю коммитов попадают .pyc-файлы, папки node_modules и секреты из .env.

В этом гайде разберём синтаксис .gitignore с примерами каждого паттерна, дадим готовые шаблоны для Python, Node.js, Java и Go, а также покажем, как исправить ситуацию, если файл уже попал в индекс. Статья рассчитана на тех, кто уже знаком с основами Git — если нужно освежить базу, начните с введения в Git.

— .gitignore поддерживает паттерны *, **, !, / и комментарии через #

— Готовые шаблоны для Python, Node.js, Java и Go закрывают 90% типичных случаев

— Глобальный ~/.gitignore_global избавляет от повторения в каждом проекте правил для IDE и ОС

— Если файл уже в индексе, git rm --cached убирает его без удаления с диска

— .gitkeep — хак для отслеживания пустых директорий

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Синтаксис .gitignore: разбираем каждый паттерн

Git читает .gitignore построчно. Пустые строки игнорируются, строки с # в начале — комментарии. Остальное — паттерны.

* — любое количество символов в имени файла (кроме /):

** — любое количество директорий (рекурсивно):

! — отмена предыдущего правила (исключение из исключений):

Важно: паттерн ! не работает, если родительская директория уже заигнорирована. Например, если в .gitignore есть строка build/, то правило !build/keep-me.txt не поможет — файл всё равно будет игнорироваться. Чтобы исключение сработало, нужно сначала разрешить саму директорию: !build/, а затем уже — конкретный файл.

/ в начале — привязка к корню репозитория:

/ в конце — игнорировать только директорию, не файл с таким же именем:

# — комментарий. Используйте для группировки правил:

Шаблон .gitignore для Python

Python генерирует .pyc-файлы и папки __pycache__ при каждом запуске. Виртуальные окружения (venv, .venv) и файлы с переменными окружения (.env) тоже не должны попадать в репозиторий.

Шаблон .gitignore для Node.js

Главная причина тяжёлых репозиториев на Node.js — папка node_modules, которую забыли добавить в .gitignore. Её размер легко достигает сотен мегабайт.

Шаблон .gitignore для Java

Java-проекты собираются Maven или Gradle — у каждого свои папки артефактов. Скомпилированные .class-файлы и .jar-архивы пересобираются при каждом билде и в репозитории не нужны.

Шаблон .gitignore для Go

Go компилирует проект в бинарник — его хранить в репозитории не нужно. Папка vendor/ содержит копии зависимостей: её включать или нет — зависит от политики команды. Если используете Go modules без vendor-режима, добавьте папку в .gitignore.

Глобальный .gitignore: один раз для всех проектов

Некоторые файлы мусорят в любом проекте — .DS_Store на macOS, Thumbs.db на Windows, файлы IDE вроде .idea/ или .vscode/. Дублировать эти правила в каждом репозитории неудобно. Для этого есть глобальный .gitignore.

Настройка через core.excludesFile:

Пример содержимого ~/.gitignore_global:

После настройки Git применяет глобальные правила автоматически во всех репозиториях на вашем компьютере — без изменения .gitignore проекта.

Ещё один способ локально игнорировать файлы — .git/info/exclude. Этот файл работает как .gitignore, но не коммитится в репозиторий и виден только вам. Удобно для временных файлов, специфичных для вашего окружения, которые не стоит выносить в глобальный ~/.gitignore_global.

Файл уже в индексе: как перестать его отслеживать

Добавить правило в .gitignore недостаточно, если файл уже был закоммичен. Git продолжит его отслеживать. Нужно убрать файл из индекса, сохранив его на диске:

После этого добавьте правило в .gitignore и закоммитьте оба изменения — удаление из индекса и обновлённый .gitignore. Сам файл останется у вас на диске, но перестанет появляться в git status.

Если нужно очистить весь индекс и применить правила заново (например, после добавления нескольких паттернов):

Внимание: эта команда пересоздаёт индекс целиком. Не запускайте её при незакоммиченных изменениях.

.gitkeep: как отслеживать пустые директории

Git не отслеживает директории — только файлы. Если папка пустая, git add её просто проигнорирует. Это проблема, когда структура директорий важна для проекта: например, logs/, uploads/, tmp/.

Решение — добавить в пустую папку файл-заглушку .gitkeep:

Файл .gitkeep — неофициальное соглашение. Никакой специальной поддержки в Git нет, это просто пустой файл с понятным именем. Некоторые команды используют .githold или .keep — принципиальной разницы нет.

Инструменты: генераторы готовых шаблонов

Не обязательно писать .gitignore с нуля — есть готовые инструменты:

• gitignore.io (toptal.com/developers/gitignore) — генератор по языку, IDE и ОС. Введите «Python», «JetBrains», «macOS» — получите готовый файл.
• GitHub gitignore templates — официальная коллекция шаблонов от GitHub. Шаблоны для 150+ языков и фреймворков. Используется как основа при создании репозитория через интерфейс GitHub.
• gh repo create — при создании репозитория через GitHub CLI можно сразу выбрать шаблон .gitignore флагом --gitignore.

Для проверки, почему конкретный файл игнорируется (или не игнорируется), используйте встроенную команду:

Итог

Правильный .gitignore — это не формальность, а часть культуры работы с репозиторием. Он защищает от утечки секретов, не даёт захламить историю коммитов и экономит время при клонировании. Начните с шаблона под ваш стек (используйте gitignore.io или GitHub-коллекцию), добавьте глобальный файл для настроек IDE, и у вас не будет проблем с лишними файлами в git status.

Если хотите разобраться с Git глубже — изучите полный путеводитель по Git на Tproger: там собраны все ключевые темы от основ до продвинутых техник.

EmDash — это новая open-source CMS (система управления контентом) на TypeScript от Cloudflare, которую компания называет «духовным наследником WordPress». Главная идея: плагины работают в изолированных песочницах и не могут навредить сайту, даже если содержат уязвимости.

• Cloudflare выпустила EmDash v0.1.0 — open-source CMS на TypeScript с MIT-лицензией
• Каждый плагин запускается в изолированной песочнице (Dynamic Workers) и декларирует нужные разрешения в манифесте
• 96% уязвимостей WordPress-сайтов приходится на плагины — EmDash решает эту проблему архитектурно
• Под капотом — Astro, serverless-архитектура, Portable Text вместо HTML, встроенный MCP-сервер для ИИ-агентов
• Проект создан за 2 месяца с помощью ИИ-агентов, доступен на GitHub (3200+ звёзд за сутки)

WordPress исполнится 23 года в этом году (основан в 2003 году). Платформа обслуживает более 40% всех сайтов в интернете, но её архитектура родом из эпохи, когда AWS EC2 ещё не существовал. Плагинная система WordPress — главное преимущество и главная боль одновременно.

Почему безопасность плагинов WordPress — нерешаемая проблема

В WordPress плагин — это PHP-скрипт, который встраивается напрямую в ядро и получает полный доступ к базе данных и файловой системе. Нет изоляции, нет ограничений. Установить плагин — значит полностью ему довериться.

Статистика Wordfence и других ИБ-компаний неутешительна:

• 96% уязвимостей WordPress-сайтов происходят из плагинов
• В 2025 году нашли больше критических уязвимостей в экосистеме WordPress, чем за два предыдущих года вместе
• Очередь ревью в маркетплейсе WordPress.org — 800+ плагинов, ожидание — минимум 2 недели

WordPress не может решить эту проблему, не переписав архитектуру с нуля. Cloudflare решила это сделать.

Как EmDash изолирует плагины

В EmDash каждый плагин запускается в собственном изолированном воркере (Dynamic Worker — легковесная v8-песочница, запускающаяся за миллисекунды). Вместо полного доступа ко всему, плагин декларирует в манифесте, какие возможности ему нужны:

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

Модель напоминает OAuth: при установке плагина вы видите, какие именно разрешения он запрашивает, и принимаете осознанное решение. Администратор может задать политики — какие capabilities допустимы для каких ролей.

Архитектура и стек

EmDash построен на современном стеке:

• TypeScript — весь код, включая плагины и темы
• Astro — фреймворк для контентных сайтов, рендеринг тем
• Portable Text — структурированный JSON вместо HTML, контент не привязан к DOM
• Serverless — масштабируется до нуля, работает на Cloudflare Workers или любом Node.js-сервере
• Passkeys — аутентификация без паролей по умолчанию (WebAuthn)
• MIT-лицензия — без ограничений GPL, плагины могут иметь любую лицензию

Хранение и совместимость

На Cloudflare EmDash использует D1 (база данных), R2 (файлы), Workers (вычисления). Но абстракции портируемы: можно запустить на SQLite, PostgreSQL, AWS S3 или локальном файловом хранилище. Команда для развёртывания:

ИИ-нативная CMS: MCP, CLI, Agent Skills

EmDash спроектирован для работы с ИИ-агентами:

• Встроенный MCP-сервер — Claude, ChatGPT и другие ИИ-инструменты могут управлять сайтом напрямую через Model Context Protocol
• Agent Skills — файлы-инструкции для ИИ-агентов: как писать плагины, портировать темы с WordPress, работать со схемами контента
• CLI — программное управление контентом, медиа, схемами

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

Встроенная монетизация через x402

Каждый сайт на EmDash поддерживает стандарт x402 — нативные интернет-платежи. Клиент (например, ИИ-агент) отправляет HTTP-запрос, получает ответ 402 Payment Required и оплачивает доступ к контенту на лету. Настроить монетизацию можно без единой строчки кода — указать, какой контент платный, и привязать кошелёк.

Миграция с WordPress

EmDash поддерживает импорт существующих WordPress-сайтов:

1. Экспорт WXR-файла (WordPress eXtended RSS) из WordPress-админки
2. Или установка плагина EmDash Exporter, который создаёт защищённый endpoint для миграции
3. Автоматический перенос постов, страниц, медиафайлов и таксономий

Кастомные типы контента (которые в WordPress требуют Advanced Custom Fields) в EmDash задаются через визуальный конструктор схем в админке.

Что стоит учесть

EmDash находится в статусе бета-превью (v0.1.0). Несколько моментов:

• Проект молодой — 62 коммита, 4 контрибьютора, 34 релиза
• Песочница для плагинов через Dynamic Workers требует платного аккаунта Cloudflare (от $5/мес), но EmDash запускается и без неё — плагины будут работать в safe mode без изоляции
• Экосистема плагинов и тем ещё не сформировалась — на старте доступны формы, встраивания, SEO, аудит-лог
• Привязка к инфраструктуре Cloudflare — можно запустить на Node.js, но максимальную производительность даёт именно Cloudflare

Выводы

WordPress — триумф open source, который дал возможность публиковаться миллионам. Но экосистеме нужен вариант, который даёт ту же свободу и доступность, решая при этом проблемы, которые WordPress не может решить.

EmDash — амбициозная заявка Cloudflare на рынок CMS. За 24 часа после анонса проект набрал более 3200 звёзд на GitHub и 600+ баллов на Hacker News. Продакшн-готовности пока нет — это бета. Но идея изолированных плагинов с декларативными разрешениями решает реальную проблему, которая мучает WordPress-экосистему десятилетиями.

Попробовать EmDash можно в онлайн-песочнице или развернуть локально через CLI.

• За 20 дней до утечки в баг-трекере Bun зафиксирован баг #28001: source maps отдаются в production mode, хотя документация утверждает обратное.
• Claude Code собирается и работает на Bun — рантайме, который Anthropic приобрела в декабре 2025 года.
• Утечка произошла через файл source map размером 59,8 МБ, попавший в npm-пакет @anthropic-ai/claude-code версии 2.1.88.
• Anthropic назвала инцидент «ошибкой при упаковке релиза, вызванной человеческим фактором». Формальный постмортем не опубликован.
• Прямого подтверждения связи между багом #28001 и утечкой нет, но техническое совпадение слишком точное, чтобы его игнорировать.

Хронология: от покупки Bun до утечки

2 декабря 2025 — Anthropic объявляет о покупке Bun, JavaScript-рантайма, на котором работает Claude Code. Создатель Bun Джаред Самнер (Jarred Sumner) переходит в Anthropic. Компания обещает сохранить Bun как open-source проект с MIT-лицензией. К этому моменту Claude Code уже приносит $1 млрд годовой выручки.

11 марта 2026 — в баг-трекере Bun появляется issue #28001: при использовании Bun.serve() с параметром development: false source maps всё равно генерируются и отдаются клиенту. Документация Bun явно указывает, что в production mode source maps должны быть отключены. Баг зафиксирован на версии 1.3.10.

31 марта 2026 — разработчик Чаофан Шоу (Chaofan Shou, @shoucccc) обнаруживает, что в npm-пакете @anthropic-ai/claude-code версии 2.1.88 лежит файл cli.js.map размером 59,8 МБ. Внутри — полный исходный код: более 500 000 строк TypeScript в ~1900 файлах. Твит набирает более 21 миллиона просмотров.

Что за баг в Bun

Баг #28001 зафиксирован в подсистеме Bun.serve() — встроенном HTTP-сервере Bun с функцией бандлинга. Суть проблемы: даже когда разработчик явно задаёт development: false, source maps всё равно генерируются и включаются в собранные файлы. Это противоречит документации Bun.

Claude Code собирается в один файл для публикации в npm через бандлер Bun. Формально баг #28001 описывает проблему в Bun.serve(), а не в автономном бандлере bun build. Однако обе подсистемы используют один и тот же механизм генерации source maps, и сообщество считает вероятным, что проблема затрагивает обе. На момент утечки issue оставался открытым и без фикса.

Само по себе наличие source map в сборке — ещё полбеды. Проблема в том, что в конвейере публикации Claude Code не было ни записи *.map в .npmignore, ни ограничения поля files в package.json. Если бы любой из этих защитных механизмов работал, source map не попала бы в npm-пакет даже при наличии бага. Сочетание двух факторов — баг в рантайме и отсутствие фильтрации при публикации — привело к утечке.

Почему сообщество обратило на это внимание

На Reddit и Hacker News историю обсуждают не столько из-за технической сложности бага — он тривиален. Внимание привлекла ирония ситуации:

• Anthropic купила Bun в декабре 2025 года. Claude Code — главный продукт компании, и он работает именно на Bun.
• Баг в Bun, связанный с source maps, был известен за 20 дней до утечки, но не был исправлен.
• Anthropic позиционирует себя как «safety-first» ИИ-компанию — и при этом допустила два инцидента с утечками за одну неделю: утечка черновиков блога о модели Mythos 26 марта и source map 31 марта.
• Компания активно рассказывает, что её ИИ пишет значительную часть кода Bun — и именно в этом коде нашёлся баг, приведший к утечке кода ИИ.

Случайно отправить source map в npm — ошибка, которая кажется невозможной, пока не вспомнишь, что значительная часть кодовой базы, вероятно, была написана тем самым ИИ, которого ты релизишь.

Что нашли внутри: краткая сводка

Мы подробно разбирали содержимое утечки в предыдущем материале. Ключевые находки:

• KAIROS — нерелизованный режим автономного фонового агента, который работает как демон, подписывается на GitHub-вебхуки и «видит сны» ночью, консолидируя память.
• Undercover Mode — режим, при котором Claude скрывает свою природу ИИ и убирает атрибуцию Co-Authored-By в коммитах. Принудительного отключения нет.
• ANTI_DISTILLATION — внедрение фейковых инструментов в API-запросы для отравления обучающих данных конкурентов.
• BUDDY — тамагочи в терминале с 18 видами существ, уровнями редкости и RPG-характеристиками.
• Внутренние бенчмарки, кодовые имена моделей (Capybara, Fennec, Numbat) и 44 фича-флага.

Реакция Anthropic

Anthropic удалила npm-пакет в течение нескольких часов и заявила, что утечка — «ошибка при упаковке релиза, вызванная человеческим фактором, а не брешь в безопасности». Пользовательские данные, ключи API и учётные записи не были скомпрометированы. Компания начала рассылать DMCA-уведомления зеркалам на GitHub, но формальный постмортем не опубликовала.

Тем временем корейский разработчик Сигрид Джин (Sigrid Jin) создал clean-room переписку архитектуры Claude Code на Python под названием claw-code. Репозиторий набрал 50 000 звёзд за два часа — по заявлению авторов, это рекорд GitHub. Сейчас проект переписывается на Rust.

Что это значит для разработчиков

Если вы используете Bun для сборки production-кода, стоит проверить свой конвейер публикации:

1. Проверьте, не попадают ли файлы .map в ваши npm-пакеты. Используйте npm pack --dry-run для аудита содержимого перед публикацией.
2. Добавьте *.map в .npmignore или явно перечислите разрешённые файлы в поле files в package.json. Второй вариант надёжнее — вместо списка исключений вы задаёте список включений.
3. Следите за issue #28001 в репозитории Bun — на момент публикации баг не исправлен.
4. Если публикуете пакеты через CI/CD — добавьте шаг валидации, который проверяет отсутствие source maps в артефакте.

Итог

История с утечкой Claude Code — наглядный пример того, как цепочка мелких упущений приводит к масштабному инциденту. Возможный баг в рантайме, отсутствие фильтрации при публикации, недостаточный аудит CI/CD-пайплайна — по отдельности каждая из этих проблем тривиальна. Вместе они обнажили более 500 000 строк проприетарного кода компании с оценкой выше $100 млрд.

Для разработчиков урок простой: не доверяйте дефолтам инструментов сборки и всегда проверяйте, что именно попадает в ваши пакеты. Команда npm pack --dry-run занимает секунды и может предотвратить утечку, которая изменит историю вашего продукта.

Скомпрометированы версии axios@1.14.1 и axios@0.30.4 — обе ветки, актуальная и легаси. Вредоносный код устанавливает кроссплатформенный RAT, который работает на macOS, Windows и Linux. Пакеты были доступны в npm-реестре около 3 часов, прежде чем npm их удалил.

— Скомпрометированы axios@1.14.1 и axios@0.30.4 через взлом npm-аккаунта мейнтейнера

— Вредоносная зависимость plain-crypto-js устанавливает RAT-троянец на все ОС

— axios — самый популярный HTTP-клиент в JS-экосистеме: более 100 млн загрузок в неделю

— Безопасные версии: 1.14.0 (для 1.x) и 0.30.3 (для 0.x)

— Все секреты на затронутых системах нужно ротировать немедленно

Axios — HTTP-клиент для Node.js и браузеров с более чем 100 миллионами загрузок в неделю. Атаки на цепочки поставок (supply chain attacks) — это компрометация инфраструктуры распространения ПО: вместо атаки на конечную цель злоумышленник внедряет вредоносный код в доверенный пакет, который жертва сама устанавливает.

Как произошла атака

Злоумышленники получили доступ к npm-аккаунту jasonsaayman — основного мейнтейнера axios. Email аккаунта был изменён с легитимного адреса на ifstap@proton.me. Предположительно, был украден долгоживущий классический npm access token.

Легитимные релизы axios публикуются через GitHub Actions с криптографической привязкой npm OIDC Trusted Publisher и содержат SLSA-провенанс (Supply chain Levels for Software Artifacts — стандарт подтверждения целостности сборки). Вредоносные версии были опубликованы вручную через npm CLI — без привязки к GitHub, без SLSA-провенанса, без соответствующего тега в репозитории.

Атака была подготовлена заранее: за 18 часов до компрометации axios в npm был опубликован пакет-приманка plain-crypto-js — клон легитимного crypto-js с тем же описанием и именем автора. Сначала чистая версия 4.2.0, затем вредоносная 4.2.1 с постустановочным скриптом.

Хронология атаки

Все события — по UTC, 30–31 марта 2026 года:

• 30 марта, 05:57 — атакующий публикует чистый plain-crypto-js@4.2.0 для формирования истории публикаций
• 30 марта, 23:59 — выходит вредоносный plain-crypto-js@4.2.1 с постустановочным скриптом
• 31 марта, 00:05 — Socket детектирует вредоносный пакет — через 6 минут после публикации
• 31 марта, 00:21 — публикуется axios@1.14.1 со скомпрометированного аккаунта
• 31 марта, 01:00 — публикуется axios@0.30.4 — обе ветки поражены за 39 минут
• 31 марта, ~03:15 — npm удаляет обе вредоносные версии, dist-tag latest откатывается к 1.14.0
• 31 марта, 04:26 — npm публикует заглушку безопасности для plain-crypto-js — пакет заблокирован

Итого: axios@1.14.1 был доступен около 2 часов 53 минут, axios@0.30.4 — около 2 часов 15 минут.

Что делает вредоносный код

В исходном коде axios изменений нет — добавлена только зависимость plain-crypto-js@^4.2.1. Сам пакет никогда не импортируется в коде; он существует исключительно для запуска postinstall-хука при npm install.

Дроппер setup.js

Файл setup.js весит 4209 байт и использует двухслойную обфускацию: сначала reversed Base64-декодирование (с подстановкой символов), затем XOR-шифр с ключом OrDeR_7077. Дроппер определяет ОС и загружает платформенный payload с C2-сервера.

Payload по платформам

macOS: AppleScript-дроппер скачивает бинарный RAT с C2-сервера и сохраняет его как /Library/Caches/com.apple.act.mond — замаскирован под системный демон Apple. Запускается через /bin/zsh.

Windows: PowerShell копируется в %PROGRAMDATA%\wt.exe (маскировка под Windows Terminal). VBScript-дроппер запускает скрытый PowerShell-скрипт с обходом Execution Policy.

Linux: Python-скрипт RAT скачивается в /tmp/ld.py и запускается через nohup в фоновом режиме.

Возможности RAT

При первом запуске RAT отправляет на C2-сервер «отпечаток» системы: hostname, имя пользователя, версию ОС, архитектуру CPU, часовой пояс, время установки ОС и загрузки, список процессов, а также содержимое директорий /Applications, ~/Library и ~/Application Support. Затем RAT опрашивает C2 каждые 60 секунд. Поддерживаемые команды:

• runscript — выполнение произвольных shell-команд и Python-кода
• peinject — загрузка и запуск дополнительных бинарных payload
• rundir — перечисление содержимого директорий
• kill — самоуничтожение процесса

Антифорензика

После выполнения дроппер удаляет себя (setup.js) и подменяет package.json чистой версией без postinstall-секции. При инспекции node_modules после заражения следов вредоносного скрипта не остаётся.

Это означает, что проверка node_modules постфактум бесполезна. Единственный надёжный способ определить компрометацию — проверить package-lock.json на наличие вредоносных версий и IoC-пути на файловой системе (см. ниже).

Кто обнаружил

Атаку независимо обнаружили несколько компаний: Socket задетектировал вредоносный plain-crypto-js через 6 минут после публикации. StepSecurity подтвердил компрометацию через AI Package Analyst и инструментирование GitHub Actions-раннера. Детальный технический разбор также опубликовала SafeDep.

Индикаторы компрометации (IoC)

Файловая система:

Сеть:

SHA256 хеши:

Что делать прямо сейчас

Быстрая проверка — есть ли вредоносные версии в вашем lockfile:

Если команда ничего не вернула — ваш проект не затронут. Если нашлись совпадения:

1. Откатить axios: npm install axios@1.14.0 (для 1.x) или npm install axios@0.30.3 (для 0.x) — это автоматически удалит plain-crypto-js
2. Проверить IoC-пути на файловой системе для вашей ОС (см. выше)
3. Заблокировать C2 на сетевом уровне: sfrclak[.]com / 142.11.206.73
4. Ротировать все секреты на затронутых системах: npm-токены, SSH-ключи, API-ключи, переменные из .env
5. Проверить CI/CD-логи за 30–31 марта — ротировать все secrets из затронутых пайплайнов
6. Перейти на npm ci --ignore-scripts в CI/CD как постоянную политику

Если обнаружены артефакты RAT — считайте систему полностью скомпрометированной и пересоберите из заведомо чистого состояния.

Защита от транзитивных зависимостей

Если axios используется как транзитивная зависимость (его тянет другой пакет), прямой npm install axios@1.14.0 не поможет — нужно зафиксировать версию через overrides в package.json:

Поле overrides работает в npm 8+, resolutions — в Yarn.

Выводы

Инцидент с axios — один из самых масштабных supply chain атак в npm по потенциальному охвату: при 100 миллионах загрузок в неделю даже 3-часовое окно доступности вредоносных версий критично. Для сравнения: компрометация event-stream в 2018 году затронула пакет с 2 миллионами загрузок в неделю.

Скорость реакции экосистемы впечатляет: Socket обнаружил вредоносный plain-crypto-js через 6 минут, npm отозвал пакеты менее чем за 3 часа. Но сам факт, что атакующему хватило одного украденного токена для публикации от имени доверенного мейнтейнера, ставит вопрос о необходимости обязательного использования OIDC Trusted Publishing для критической инфраструктуры npm.

Проверьте свои зависимости, ротируйте секреты и убедитесь, что ваш CI/CD-пайплайн защищён от автоматической установки непроверенных версий.

Почему релиз Node.js 22 важен

30 апреля 2025 года завершился жизненный цикл версии Node.js 18. Сообщество заранее предупреждало об этом через официальный аккаунт в X. Там напомнили разработчикам о необходимости перейти на более свежие версии — Node.js 20 или 22. Восемнадцатая версия перестала получать патчи безопасности, поэтому обновление стало критичным для поддержания стабильной работы приложений.

Наиболее надёжным вариантом стала миграция на Node.js 22, которая сейчас находится в статусе долгосрочной поддержки (LTS) и гарантирует обновления безопасности и стабильность на ближайшие годы.

Хотя релиз этой версии не выглядел революционным, он существенно изменил основу платформы. Многие возможности, которые раньше требовали внешних библиотек, теперь встроены прямо в платформу: WebSocket-клиент, стабильный fetch(), работа с файлами, Blob и URL, улучшенная совместимость ESM и CommonJS. Это уменьшает количество зависимостей, снижает вероятность уязвимостей и значительно упрощает поддержку проектов.

Помимо удобства разработки, в новой версии усилились производительность и безопасность. Обновлённый движок V8 ускоряет выполнение кода, а оптимизация старта и снижение потребления памяти делают Node.js более стабильным в высоконагруженных и serverless-сценариях. Улучшенная модель разрешений, строгие настройки TLS и расширенная поддержка AbortController повышают защиту на уровне рантайма, ограничивая последствия уязвимостей в сторонних пакетах. Это даёт компаниям возможность строить более надёжные сервисы с меньшими затратами на контроль рисков и эксплуатацию.

Node.js 22 также стал удобнее для работы гибридных команд. Стабильная интеграция ESM и CommonJS облегчает миграцию старых проектов, а унификация Web-API делает код универсальным и понятным даже для сотрудников без глубокого опыта в бэкенде. Улучшенные инструменты тестирования и диагностики повышают прозрачность разработки и снижают время на нахождение ошибок.

Node.js 22 — эволюционный релиз. Он развивает ранее введённые возможности (fetch, ESM, WebSocket и др.), но не переворачивает парадигму разработки. Это укрепление уже заданного курса.

Возможности Node.js 22

Расширение JavaScript и обновление V8. Получив движок V8 12.x, Node.js подтянул все улучшения ECMAScript 2024. Код стал исполняться быстрее как за счёт оптимизаций в компиляторе, так и благодаря улучшенной работе с асинхронностью. Например, async/await теперь обрабатываются эффективнее, а создание структур данных, активно используемых в серверах, стало менее затратным.

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

Corepack включён по умолчанию. До выхода Node.js 22 разработчики сами решали, подключать ли Corepack. Теперь он активен без дополнительной настройки, и это серьёзное изменение в экосистеме. Все менеджеры пакетов контролируются единой прослойкой, что устраняет зависимость от версии, установленной глобально у разработчика или в CI.

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

Corepack, как мне кажется, сильно упростит жизнь большим командам. Исчезает вечная история “а у меня Yarn другой версии” или “Pnpm не подтянулся”. Corepack берёт на себя управление версионированием менеджеров пакетов, а значит, сборки становятся более воспроизводимыми. Для корпоративных проектов это плюс, особенно если речь идёт о распределённых командах или CI/CD-конвейерах.

WebSocket API и улучшенные Web Streams. Node.js 22 внедрил нативную поддержку WebSocket API. Теперь можно создавать WebSocket-клиенты и серверы без сторонних библиотек вроде ws. Это делает код чище и ближе к браузерному API.

Параллельно были улучшены Web Streams. Работа с потоками стала предсказуемой, а инструменты вроде CompressionStream и DecompressionStream функционируют так же, как и в современных браузерах. Поддержка универсального кода — сервер + клиент — стала проще, а объём внешних зависимостей уменьшился.

Улучшения в работе CommonJS и ESM. Node.js постепенно движется в сторону ESM, но у огромного количества проектов всё ещё используется CommonJS. В новой версии улучшена производительность смешанных проектов и сокращены ошибки при импорте модулей между двумя системами. Между ними появилось меньше «подводных камней», а значит миграция на ESM может идти постепенно, без ломки архитектуры.

Стабильный встроенный fetch(). Его реализация теперь полностью совпадает с браузерной, так что в простых кейсах можно отказаться от axios или node-fetch. Меньше зависимостей — быстрее запуск и меньше технического долга.

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

Я бы отметил более зрелую работу с Permission Model. Она уже не экспериментальная и реально помогает ограничивать доступ к файловой системе и сети. Параллельно улучшилась производительность V8, а вместе с ней и общая отзывчивость серверных приложений. Подтянули и Web-стек: стабильнее стали Web Streams, Request/Response и другие API, которые сближают Node с браузерами. Всё это не революция, но тренд на унификацию растёт.

Расширенные возможности тестирования. Node.js продолжает развивать встроенный тестовый фреймворк node:test. Теперь доступны кастомные репортеры, покрытие кода без внешних инструментов и mock timers (замена реальной работы таймеров). Это позволяет использовать встроенный тест-раннер для большинства задач, отказавшись от Jest или Vitest в простых проектах.

Обновления в безопасности. Обновление OpenSSL — одно из самых чувствительных изменений в релизе. Поддержка старых криптоалгоритмов исключена, проверка сертификатов стала строже, а взаимодействие по TLS 1.3 стабильнее.

С точки зрения безопасности рывка не произошло, но заметное движение есть: Permission Model, улучшенная работа с OpenSSL, более аккуратная валидация входящих данных. Всё это снижает риски, но полностью опасность не снимает, потому что реальная безопасность всё равно лежит в архитектуре, процессов CI/CD и культуре разработки.

Повышенная производительность. Заметные улучшения коснулись старта приложения, работы с памятью и производительности под нагрузкой. Приложения запускаются быстрее, а распределение нагрузки между worker threads стало более эффективным. Это позволит обслуживать больше запросов при тех же ресурсах и уменьшить расходы на инфраструктуру.

Международные стандарты и локализация. Были обновлены Intl API на базе новой версии ICU. Преимущества: точные часовые пояса, поддержка новых календарей и систем чисел. Это критично для глобальных SaaS-платформ, аналитических сервисов и финтех-продуктов.

По словам Даниила Гоника, для разработчиков наиболее значимы такие изменения, как WebSocket-клиент, модульная система., обновление V8, улучшение JIT-компиляторов, добавление новых возможностей JS и улучшение встроенного test-раннера.

Как безопасно мигрировать на Node.js 22

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

После этого нужно прогнать тесты. Даже минимальный набор позволит выявить проблемы, связанные с изменениями в ESM/CJS, WebSocket API или OpenSSL.

Само обновление среды зависит от выбранного инструмента. Через nvm или n процесс занимает секунды, а для Docker достаточно указать новый базовый образ. Если проект использует CI/CD, стоит уделить внимание Corepack: теперь он активен всегда, что может изменить поведение сборки.

После обновления полезно проверить логи и внимательно изучить предупреждения. Большинство проблем решается установкой последних версий библиотек, иногда — правкой конфигурации TLS или обновлением менеджера пакетов.

Обновление стоит внедрять поэтапно, начиная со staging или частичного продакшена, и держать готовность к откату.

Я обычно советую подход двухконтурного обновления. Сначала поднять проект на 22-ю версию в отдельной среде, включить максимальный объём логов, запустить тесты и прогнать реальные сценарии. Потом обновить линтеры, сборщики и самые старые пакеты, чтобы убрать накопленные за годы предупреждения. И только когда всё стабильно, имеет смысл переключать продакшен. По сути, обновление Node нужно делать так же аккуратно, как обновление облачных сервисов: через изоляцию, наблюдаемость и бэкап-стратегию.

В Node.js 22 удалены некоторые устаревшие, малоиспользуемые функции, поэтому при переходе может потребоваться рефакторинг мест, где они использовались. Следует проверить депрекейты: Node.js 22 помечает ряд старых возможностей как устаревшие и предлагает альтернативы. Необходимо убедиться, что все библиотеки и пакеты, используемые проектом, поддерживают новую версию Node.js.
При скачке сразу с 18/20 на 22 некоторые зависимости могут оказаться несовместимыми с обновлённым движком V8 или новыми APIs — может понадобиться их обновление до последних версий.

Кому стоит подождать с переходом

Переход на Node.js 22 подходит не всем проектам. В некоторых ситуациях разумнее подождать, чтобы избежать регрессий и поломок в продакшене. Вот кому стоит повременить с переходом:

• Тем, кто использует инструменты сборки или менеджеры пакетов, которые ещё не совместимы с Node.js 22 и могут выдавать ошибки или не работать вовсе.​
• Командам, которые работают на старых версиях ОС. Известны проблемы совместимости с macOS 10.14 и ниже, а также возможны ошибки на Windows при миграции старых приложений.​
• Тем, чьи CI/CD, контейнеры или Docker-образцы завязаны на конкретные версии Node.js и npm. Переход на 22-ю версию требует много регрессионного тестирования.​
• Проектам с критически важными C++-добавками. Смена major-версии влечёт за собой обновление бинарных интерфейсов, что может вызывать ошибки при компиляции нативных модулей.
• Пользователям определённых интеграций. Для некоторых версий MongoDB‑драйверов зафиксированы фатальные баги после перехода на конкретные промежуточные версии Node.js 22.x.​
• Если вы используете проекты, которые сами рекомендуют Node.js 18 или 20, а обновление их зависимостей под 22 только планируется.

В продакшене чаще всего проблемы возникают не из-за самих изменений в платформе, а из-за того, как эти изменения проявляются в реальных проектах. Где-то обновился V8 и стал вести себя строже, где-то повылезали deprecated-модули, а где-то просто сломались сборщики или старые зависимости. Многие команды до сих пор живут на Webpack 4, Express 4 или TypeORM старых версий: вот они первыми столкнутся со сложностями.

Что дальше

Среди будущих трендов в экосистеме Node.js Максим Захаренко выделяет следующие: «Первое — постепенное сближение Node с Web-стеком, чтобы код становился максимально универсальным. Второе — рост влияния Bun и Deno, которые будут подталкивать Node к более агрессивной оптимизации. И третье — всё более активная интеграция с AI-инструментами, особенно в DevTools и в цепочках генерации кода».

Всё больше веб-API внедряются в Node.js (fetch, WebSocket, EventTarget). Этот тренд будет продолжаться. ESM становится стандартом, поддержка будет расширяться, CommonJS постепенно уйдёт в прошлое. Расширяется WASI и поддержка WASM-модулей. Node.js движется в сторону мульти-языковой среды. Модель прав доступа и другие sandbox-механизмы также продолжат развиваться. Кроме того, в версии Node.js 22.5.0 экспериментально добавлен встроенный модуль SQLite (через –experimental-sqlite). Это важное уточнение: в релизе 22.0.0 SQLite отсутствовал.

Даниил Гоник хотел бы увидеть в будущих релизах стабильную и удобную модель разрешений, возможность require() для ESM без флагов, улучшения в DevX: поддержка TS «из коробки», больше инструментов в ядре, расширение SEA (Single Executable Apps) и встроенные механизмы верификации зависимостей (подписи, integrity).

Выводы

Node.js 22 делает приложения быстрее, безопаснее и совместимее с Web API, улучшает работу с памятью и снижает зависимость от глобальных инструментов. Хотя переход требует подготовки, он не представляет серьёзных рисков, если следовать базовой процедуре: проверить зависимости, прогнать тесты и обновить среду постепенно. Если инфраструктура современная, а стек устойчивый, переход на Node.js 22 принесёт ощутимые преимущества как в скорости работы, так и в удобстве разработки.

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

Но теперь эта «шутка» стала наглядной — проект Stacktower превращает рисунок в настоящую визуализацию зависимостей.

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

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

Как работает Stacktower

Сайт предлагает две модели: «стабильную башню» и «неустойчивую башню», где уровни подстраиваются под выбранные библиотеки.

Пользователь может загрузить зависимости своих приложений — например, на Python или JavaScript — и увидеть, что будет, если убрать даже один элемент.

На странице приводится пример для Node.js:

приложение зависит от Express → Express зависит от body-parser → body-parser зависит от qs → и так далее

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

Есть и Python-вариант:

импорт Flask тянет Werkzeug, Jinja2, MarkupSafe, Click и еще несколько пакетов. А те, в свою очередь, имеют собственные зависимости.

Зачем это нужно

Автор подчеркивает: цель проекта — не критиковать экосистемы, а показать их реальное устройство.

Стек современных приложений неизбежно сложен и даже крошечный модуль может стать критически важным. Именно так в 2022 году случайное удаление библиотеки left-pad временно «сломало» огромный кусок JavaScript-мира.

Stacktower превращает эту абстрактную проблему в понятный визуальный эффект: убираешь одну зависимость — рушится вся конструкция.

Комьюнити уже подхватило идею

Проект быстро разошелся по Reddit, Hacker News и X: разработчики делятся скриншотами своих «башен», спорят о хрупкости экосистем и обсуждают, стоит ли пересматривать подход к зависимости.

Кто-то предлагает добавить поддержку Rust и Go, другие мечтают о корпоративной версии инструмента для визуального аудита безопасности.

Изучить проект подробнее можно на его странице на GitHub.

В повседневной работе с JavaScript нам часто приходится проверять значение переменной перед тем, как присвоить ей новое. Подобные проверки быстро превращаются в шаблон, особенно если вы работаете с props в компонентах, глобальными настройками или объектами состояния.

Именно здесь на помощь приходят логические операторы присваивания — компактное нововведение стандарта ES2021, которое позволяет сократить типичные условные конструкции, не меняя при этом саму логику кода.

Что такое логические операторы присваивания?

Логические операторы присваивания объединяют обычный логический оператор (||, && или ??) с оператором присваивания (=), создавая короткую и наглядную запись.

По сути, это синтаксический сахар, позволяющий писать условное присваивание в одну строку. При этом они работают по тому же принципу, что и обычные логические выражения: правая часть вычисляется только в том случае, если левая не проходит логическую проверку — то есть оказывается falsy, truthy или nullish (в зависимости от конкретного оператора).

Примечание: Оператор опциональной последовательности (?.) нельзя использовать в левой части логического присваивания.

Попытка сделать это приведёт к синтаксической ошибке:

Если нужно безопасно присвоить значение, используйте обычную проверку или промежуточную переменную:

Оператор опциональной последовательности (?.) возвращает значение свойства, а не ссылку на само свойство.

А поскольку в JavaScript присваивание возможно только в том случае, если левая часть выражения является ссылкой (например, переменной или свойством объекта), использование ?. в левой части делает выражение некорректным.

Логическое присваивание через OR (||=)

Оператор ||= выполняет присваивание только тогда, когда значение слева является ложным (falsy) — то есть false, 0, “”, null, undefined или NaN.

Присвоить, если значение — falsy.

Это эквивалент записи:

Этот оператор удобен, чтобы задать значение по умолчанию, если переменная ещё не инициализирована. Однако он перезаписывает такие значения, как 0, ” или false, даже если они были установлены специально.

Другой способ задать значения по умолчанию — использовать параметры функций с дефолтными значениями. Подробнее об этом можно прочитать в статье о параметрах по умолчанию в JavaScript.

Логическое присваивание через AND (&&=)

Присвоить, если значение — truthy:

Этот оператор полезен, когда нужно обновить значение только при наличии уже существующего truthy значения.

Примечание: при использовании &&= правая часть выражения вычисляется только если левая часть является truthy, и результат этого вычисления присваивается, даже если он окажется falsy.

Исходное значение (true) играет роль «ворот»: именно оно определяет, выполняется ли присваивание.

Однако новое значение берётся из результата вызова checkPermissions (или любого выражения справа).

Важно: оператор &&= не сохраняет старое значение, а заменяет его результатом вычисления правой части.

Присваивание через nullish-оператор (??=)

Присвоить, если значение — null или undefined:

Эквивалентно:

Используйте ??=, когда нужно задать значение только если переменная действительно отсутствует — то есть равна null или undefined, а не просто falsy. В отличие от ||=, этот оператор сохраняет корректные значения, такие как 0, false и ”.

Подробнее: если хотите глубже разобраться в механике nullish-оператора и принципах работы с дефолтными значениями — посмотрите материал о том, как грамотно использовать значения по умолчанию в JavaScript.

Значения по умолчанию для пропсов компонентов

Логические операторы присваивания особенно удобны при работе с пропсами в компонентах.

Например, если часть значений не передана, можно задать дефолты прямо в коде:

Такой подход:

• делает код компактнее и читаемее,
• избавляет от лишних if или тернарных выражений,
• позволяет контролировать поведение пропсов при разных типах значений (null, undefined, false, ”).

Идеально подходит для случаев, когда вы хотите задать понятные значения по умолчанию, не ломая текущую логику компонента.

Важно учитывать

• Оператор ||= срабатывает, когда левая часть — falsy-значение (0, ”, false, null, undefined). Это может привести к нежелательному перезаписыванию:

• Используйте ??= если нужно проверять только на null или undefined, сохраняя корректные falsy-значения (0, ”, false).
• Правая часть вычисляется только при необходимости, что сохраняет производительность и предотвращает побочные эффекты:

Пример с побочным эффектом

В этом примере:

• Изначально obj.val равно 0, что является falsy. Поэтому выражение ++calls вычисляется и присваивается obj.val.
• После первой строки obj.val становится 1 (truthy).
• На второй строке условие уже не выполняется, и ++calls не вызывается.

В результате значение calls остаётся равным 1, потому что вторая операция не выполняет инкремент.

Поддержка браузерами

Логические операторы присваивания поддерживаются всеми современными окружениями:

✅ Chrome 85+, Firefox 79+, Safari 14+, Edge 85+

✅ Node.js 15+

❌ Internet Explorer — не поддерживается

Если нужно обеспечить работу в старых окружениях, используйте транспайлер, например, @babel/preset-env с настройками ES2021.

Теперь вы готовы!

Логические операторы присваивания — небольшое, но очень полезное дополнение к JavaScript. Они делают код понятнее, уменьшают шаблонные конструкции и упрощают условную логику.

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

• при работе с props и state;
• при задании значений по умолчанию для API;
• при очистке и валидации форм.

Если вы уже уверенно используете ||, && и ??, переход на ||=, &&= и ??= будет естественным — здесь всё дело лишь в привычке.

Теперь Bun официально позиционируется как full-stack платформа для фронтенда и бэкенда. И она объединяет сервер, сборщик, менеджер пакетов вместе с тест-раннером в одном инструменте.

В новую версию добавлены десятки ключевых функций: встроенные клиенты для Redis, MySQL, PostgreSQL и SQLite, единый SQL API, улучшенные WebSocket-модули, переработанный тест-раннер и поддержка VSCode Test Explorer.

Full-stack по-умному

Главное новшество — режим full-stack Bun.serve() с поддержкой роутинга, cookies и WebSockets.

Теперь фронтенд и бэкенд можно запускать в одном процессе без проблем с CORS, а приложение собрать в единый исполняемый файл с помощью bun build --compile.

Разработчики могут напрямую импортировать HTML, запускать React-приложения с хот-перезагрузкой и собирать проект одной командой bun init --react. По данным команды, скомпилированные React-приложения в Bun работают до 1,8 раза быстрее, чем через nginx.

Новый SQL и встроенный Redis

Bun 1.3 представил унифицированный Bun.SQL API — теперь один и тот же код работает с MySQL, PostgreSQL, SQLite и MariaDB. Добавлен хелпер sql.array() для работы с массивами в PostgreSQL, улучшена поддержка JSON и Unix-сокетов.

Кроме того, в рантайм встроен Redis-клиент, который поддерживает 66 команд, автоматическое переподключение, очереди сообщений и Pub/Sub. По данным разработчиков, он значительно быстрее ioredis, а поддержка кластеров и Lua-скриптов появится в будущих релизах.

Новые возможности

Среди прочих улучшений — Zstandard-сжатие, нативная поддержка YAML, API для безопасного хранения секретов (Bun.secrets), и серьезный прирост производительности: операции с криптографией ускорены до 400х, установка пакетов — до 2,5х.

Также обновлен менеджер пакетов с интерактивным bun update, изолированными установками и API для проверки безопасности зависимостей.

Почему это важно

Bun 1.3 превращает экспериментальный рантайм в полноценную платформу для веб-разработки, способную заменить Node.js, Vite и Redis-CLI одновременно.

Разработчики называют релиз «началом новой эпохи», цель которой — сделать Bun лучшим способом писать и развертывать JavaScript-приложения.

Чтобы помочь вам выбрать программу, я проанализировала около 50 предложений от онлайн-школ. В итоге отобрала 33 курса: топ-10 лучших программ, 8 узкоспециализированных вариантов, 10 курсов смежных направлений для расширения компетенций и 5 бесплатных уроков для старта.

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

ТОП-10 лучших курсов Node.js в 2026 году

1. Backend Node.js-разработчик от Нетологии — бэкенд без нового языка: одна технология для перехода на уровень middle с тремя реальными проектами и английским для IT.
2. Fullstack-разработчик на Node.js от Eduson Academy — стажировка в IT-компании во время обучения + 10 проектов в портфолио и гарантия трудоустройства с полным возвратом средств.
3. Node.js от Skillbox — бесплатный старт с персональным темпом: мгновенный доступ к материалам и поддержка кураторов с проверкой домашних заданий.
4. Бэкенд на Node.js для фронтенд-разработчиков от Яндекс Практикум — 3,5 месяца до полноценного бэкенд-специалиста: Express, MongoDB, Nest.js, PostgreSQL и деплой через Docker.
5. Node.js Developer от OTUS.ru — архитектура Node.js + TypeScript с GraphQL, WebSockets и TDD под руководством практикующих разработчиков.
6. Node.js-разработчик от Хекслет — 10 месяцев с нуля до профуровня: Fastify, Git, Jest, линтеры и четыре проекта от игр до таск-сервиса.
7. NodeJS - с нуля от PurpleSchool — пожизненный доступ + налоговый вычет: от основ JavaScript до Telegram-бота и VPS-деплоя.
8. Fullstack-разработчик на Node.js от Хекслет — шесть проектов в портфолио с первого дня + подготовка к собеседованиям и вакансии партнеров.
9. Backend разработчик на Node.js от PurpleSchool — NestJS с MongoDB-агрегациями + два бесплатных модуля и карьерная карта для новичков.
10. Backend разработка на Node.js от Merion Academy — живые сессии с разбором V8 и Event Loop + SQLite/PostgreSQL с паспорт-аутентификацией и NGINX.

Обучение Node.js подойдет тем, кто уже знаком с JavaScript, но хочет освоить серверную сторону и увеличить доход. Отличный выбор для фронтенд-разработчиков, которые устали зависеть от бэкендеров и хотят сами создавать полноценные приложения. Также курсы станут находкой для начинающих, которые ищут точку входа в IT через универсальную технологию. Если уже пробовали писать код и хотите разобраться в создании API, работе с базами и деплое — вам сюда.

Онлайн-курсы Node.js

1. Backend Node.js-разработчик | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

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

• Стоимость: 28 500 рублей
• Длительность: 6 месяцев
• Формат обучения: видеолекции, практические задания
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• будущим fullstack-разработчикам;
• тем, кто хочет перейти на middle-уровень.

Преимущества:

• персональное предложение со скидкой после консультации;
• три проекта для резюме: веб-библиотека, сервис доставки еды и агрегатор гостиниц;
• бесплатная проверка начальных знаний;
• свыше сорока задач для отработки навыков;
• возможность заниматься с любого устройства через приложение;
• постоянный офлайн-доступ к учебным файлам;
• дополнительный блок по техническому английскому в IT.

Недостатки:

• курс в формате видеозаписи без живого общения с преподавателями.

Программа обучения:

• Развертывание рабочего окружения Node.js
• Основы веб-разработки на фреймворке Express.js
• Создание работающего приложения как курсовой работы
• Внедрение статической типизации через TypeScript
• Переход на enterprise-фреймворк Nest.js
• Cloud-решения для хранения данных от Yandex Cloud
• Финальный проект — многомодульный сайт-агрегатор

Ознакомиться с полной программой >>>

2. Fullstack-разработчик на Node.js | Eduson Academy

Это путь с нуля до универсального разработчика, владеющего полным циклом создания программных решений на JavaScript и Node.js. Практическая часть включает стажировку в профильной компании, что является ступенью к удаленной работе. Курс подходит для глубокого изучения backend и frontend, и эти компетенции можно интегрировать в свою текущую работу или использовать для кардинальной смены профессии. Результатом становится систематизация знаний через практику и пополнение портфолио десятью значимыми работами, что ведет к увеличению конкурентоспособности и доходности специалиста.

• Стоимость: 149 976 рублей
• Длительность: от 11,5 месяцев
• Формат обучения: видеолекции, скринкасты, тренажеры, практические задания, тесты
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет:

• тем, кто хочет освоить новую IT-профессию;
• начинающим JavaScript-разработчикам;
• смежным специалистам в сфере IT.

Преимущества:

• портфолио из десяти полноценных проектов;
• стажировка в IT-компании параллельно с учебным процессом;
• второй курс в подарок при быстрой регистрации;
• гарантия трудоустройства или полный возврат средств;
• гибкий график с полностью онлайн-форматом;
• поддержка персонального куратора без выходных.

Недостатки:

• не хватает онлайн-вебинаров.

Программа обучения:

• Жизненный цикл программного обеспечения
• Введение в профессию fullstack-разработчика
• Основные инструменты разработчика
• Базовая верстка: HTML и CSS
• Работа с готовыми макетами сайтов
• Базовый синтаксис JavaScript
• Продвинутые концепции JavaScript
• Стиль и качество написания кода
• Интеграция TypeScript в разработку
• Применение Node.js в реальных задачах
• Публикация и сопровождение готовых проектов
• Построение карьеры в ИТ-индустрии
• Специфика удаленного формата работы

Ознакомиться с полной программой >>>

3. Node.js | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 50%

Получить скидку >>>

Обучение направлено на расширение технического кругозора через освоение полного цикла разработки — от клиентского кода до серверной логики. Выпускники получают возможность самостоятельной разработки работающих в реальном времени веб-сервисов. Освоение backend-разработки на JavaScript с использованием Node.js дает четкое представление о взаимодействии клиентской и серверной архитектуры, усиливая конкурентные преимущества специалиста.

• Стоимость: 43 026 рублей
• Длительность: 2 месяца
• Формат обучения: видеолекции, практические задания, тесты, работа над проектами
• Сертификат: сертификат установленного образца

Кому подойдет:

• frontend-разработчикам;
• backend-разработчикам.

Преимущества:

• помощь в выборе профессии после оформления заявки;
• бесплатный доступ к стартовым модулям программ;
• полезный подарок для новых слушателей;
• постоянный доступ к материалам курса;
• обучение в персонализированном темпе;
• практическая направленность материала;
• мгновенный старт занятий после оплаты;
• проверка домашних работ кураторами;
• бесплатный доступ к платформе для изучения английского.

Недостатки:

• не предусмотрена помощь с трудоустройством;
• ограниченное количество мест на программу.

Программа обучения:

• Настройка рабочего окружения
• Решение базовых задач на языке
• Работа с асинхронным кодом
• Проектирование реляционных баз данных
• Использование нереляционных хранилищ данных
• Создание CLI-приложений
• Углубленное изучение теоретических основ
• Реализация real-time функциональности через WebSockets
• Дипломный проект: сервис для ведения личных заметок

Ознакомиться с полной программой >>>

4. Бэкенд на Node.js для фронтенд-разработчиков | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

За три с половиной месяца обучения формируются навыки создания API на Express с подключением MongoDB и Mongoose, реализации систем авторизации и регистрации, а также поддержки и модификации работающих приложений. Осваивается взаимодействие с базами данных через SQL, безопасная передача данных между клиентской и серверной частью и деплой обеих составляющих без использования контейнеризации. Дополнительно изучается разработка приложений на Nest.js с PostgreSQL, покрытие бэкенда юнит-тестами и развертывание проектов через Docker и Docker Compose.

• Стоимость: 62 000 рублей
• Длительность: 3,5 месяца
• Формат обучения: текстовые материалы, вебинары, тренажеры, проектная работа
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• тем, кто знаком с основами JavaScript, TypeScript и Git;
• специалистам по фронтенд для перехода на фулстек-разработку.

Преимущества:

• нагрузка от 15 часов в неделю с возможностью совмещения с работой;
• ревью кода от опытных разработчиков;
• два готовых проекта для личного портфолио;
• обучение по спринтам с гибким графиком;
• бесплатный старт для ознакомления с программой;
• перенос дедлайнов при возникновении сложностей;
• постоянный доступ к тренажеру для практики.

Недостатки:

• не для новичков.

Программа обучения:

• Введение в основы бэкенд-разработки
• Освоение связки Node.js, фреймворка Express и MongoDB
• Создание веб-приложений с использованием Nest.js
• Работа с базами данных через PostgreSQL
• Развертывание и настройка удаленного сервера

Ознакомиться с полной программой >>>

5. Node.js Developer | OTUS.ru

Слушатели осваивают архитектурные особенности Node.js и учатся писать структурированный код на TypeScript. Курс предусматривает работу с системами управления базами данных MongoDB и PostgreSQL, где отдельное внимание уделяется построению и оптимизации запросов. Применение методологии TDD, создание серверов GraphQL с использованием Apollo и интеграция Web Sockets посредством Socket.IO в совокупности обеспечивают комплексное развитие навыков разработчика.

• Стоимость: 71 000 рублей
• Длительность: 4 месяца
• Формат обучения: интерактивные вебинары, домашние задания, работа над проектами
• Сертификат: сертификат установленного образца

Кому подойдет:

• разработчикам с опытом программирования на JS.

Преимущества:

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

Недостатки:

• необходимо ждать начала обучения.

Программа обучения:

• Фундаментальные основы Node.js в сочетании с TypeScript
• Создание веб-серверов и методы работы с данными
• Развертывание инфраструктуры и вывод проектов в продакшн
• Изучение современных API-технологий GraphQL и tRPC
• Завершающая проектная работа для закрепления навыков

Ознакомиться с полной программой >>>

6. Node.js-разработчик | Хекслет

Десятимесячная программа позволяет освоить работу в экосистеме Node.js, верстку с применением HTML и CSS, создание веб-приложений через фреймворк Fastify. Слушатели изучают составление SQL-запросов и работу с СУБД PostgreSQL, систему контроля версий Git, разработку асинхронных приложений на Node.js. Дополнительно приобретаются навыки тестирования кода с помощью Jest, проектирования архитектуры приложений и API, поддержания качества кода через линтеры.

• Стоимость: 89 000 рублей
• Длительность: 10 месяцев
• Формат обучения: видеолекции, упражнения, проектная работа
• Сертификат: сертификат установленного образца

Кому подойдет:

• изучавшим JS самостоятельно;
• начинающим фронтендерам;
• IT-специалистам для перехода в fullstack-разработку.

Преимущества:

• скидка до 31 000 рублей на полную программу обучения;
• четыре проекта в портфолио на GitHub — от игровых приложений до сервиса задач;
• доступ к вакансиям от партнеров школы;
• поддержка наставников, работающих в разработке;
• пять бесплатных вводных уроков;
• подготовка к job-hunting и прохождению интервью;
• специализированный курс технического английского.

Недостатки:

• нет постоянного набора.

Программа обучения:

• Изучение фундаментальных основ программирования
• Углубленное освоение языка JavaScript
• Работа с асинхронными операциями и сетевыми запросами
• Создание полноценных веб-приложений
• Освоение TypeScript от базового синтаксиса до продвинутых техник

Ознакомиться с полной программой >>>

7. NodeJS - с нуля | PurpleSchool

После обучения выпускники получают компетенции в разработке приложений на NodeJS, построении архитектуры масштабируемых решений и понимании внутренней структуры NodeJS и движка V8. Приобретаются знания о работе Event Loop, навыки программирования на TypeScript, применения Dependency Injection и создания легко поддерживаемого кода. Изучаются интеграционные процессы с внешними API, методы анализа производительности и утечек памяти, создание собственных промежуточных обработчиков, реализация механизмов авторизации и защитных элементов для API.

• Стоимость: от 3 999 рублей
• Длительность: от 2 месяцев
• Формат обучения: видеоуроки с конспектами, упражнения, тесты, домашние задания
• Сертификат: сертификат установленного образца

Кому подойдет:

• тем, кто знаком с TypeScript и JavaScript.

Преимущества:

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

Недостатки:

• код-ревью домашних заданий доступно на более дорогих тарифах.

Программа обучения:

• Изучение возможностей Node.js для бэкенд-разработки
• Настройка рабочего окружения и вводный модуль
• Многопоточность и внутреннее устройство движка V8
• Применение менеджера пакетов Node Package Manager
• Создание консольного CLI-приложения
• Разработка API с использованием Express.js
• Интеграция TypeScript в проект
• Анализ архитектурных решений и методы их оптимизации
• Работа с базами данных, системами авторизации и тестированием

Ознакомиться с полной программой >>>

8. Fullstack-разработчик на Node.js | Хекслет

Программа формирует навыки создания сайтов и веб-приложений с нуля, верстки страниц на HTML и CSS, освоения языка программирования JavaScript. К финалу обучения портфолио пополняется шестью проектами, что создает существенные предпосылки для трудоустройства на позицию fullstack-разработчика. Наставники обеспечивают поддержку на всех стадиях обучения. Полученные компетенции в JavaScript и веб-верстке открывают доступ к участию в перспективных и финансово привлекательных проектах.

• Стоимость: от 139 000 рублей
• Длительность: 16 месяцев
• Формат обучения: видеолекции, упражнения, проектная работа
• Сертификат: сертификат установленного образца

Кому подойдет:

• новичкам, которые хотят стать востребованными IT-специалистами;
• IT-специалистам, решившим сменить профиль;
• fullstack-разработчикам для актуализации компетенций.

Преимущества:

• бронирование текущей цены со скидкой после оставления контактов;
• шесть проектов в портфолио на GitHub — от текстовой игры до функционального мессенджера;
• поддержка наставников-разработчиков из индустрии;
• доступ к вакансиям от компаний-партнеров;
• обучение в индивидуальном темпе без жестких дедлайнов;
• практическая направленность занятий с первого дня.

Недостатки:

• некоторым пользователям курс покажется долгим.

Программа обучения:

• Основы современной верстки
• Базовые принципы верстки контента
• Позиционирование элементов средствами CSS
• Работа с модулем Flexbox
• Верстка по технологии CSS Grid
• Фундамент языка JavaScript
• Методы работы с массивами
• Принципы работы с объектами
• Введение в систему контроля версий Git
• Подготовка к процессу трудоустройства
• Введение в устройство интернета
• Применение регулярных выражений
• Изучение протокола HTTP
• Углубленное тестирование кода

Ознакомиться с полной программой >>>

9. Backend разработчик на Node.js | PurpleSchool

Курс начинается с настройки рабочего окружения Node.JS, знакомства с TypeScript и перехода к фреймворку NestJS. Программа включает разбор основных компонентов: сервисов, модулей и контроллеров, с последующим развертыванием базы данных и началом работы с ней. Изучаются методы валидации входящих данных, принципы организации авторизации. Значительный блок посвящается тестированию и отладке приложений, востребованным в реальной разработке. Для углубленного изучения предусмотрено рассмотрение агрегаций и функций в MongoDB.

• Стоимость: от 3 999 рублей
• Длительность: от 2 месяцев
• Формат обучения: видеоуроки, конспекты, упражнения, тесты
• Сертификат: сертификат установленного образца

Кому подойдет:

• разработчикам;
• смежным IT-специалистам;
• всем, кто владеет JavaScript на базовом уровне.

Преимущества:

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

Недостатки:

• домашние задания с проверкой недоступны на базовом тарифе.

Программа обучения:

• Изучение возможностей и преимуществ фреймворка
• Настройка профессиональной среды разработки
• Освоение типов и структур в TypeScript
• Введение в модули, контроллеры и провайдеры
• Практическая работа с базами данных
• Изучение типов тестирования и отладки приложений
• Реализация валидации и систем авторизации

Ознакомиться с полной программой >>>

10. Backend разработка на Node.js | Merion Academy

Студенты разбираются с Node.js: установкой через npm, развертыванием сервера и созданием API под клиентские нужды. Осваивают базы данных на SQLite — выполняют базовые операции с данными. Организуют маршрутизацию, осваивают REST API, учатся передавать и обрабатывать запросы. В финале выкладывают проект на VPS с настройкой NGINX, подключают PostgreSQL и внедряют аутентификацию на Passport.js.

• Стоимость: 8 920 рублей
• Длительность: 2 месяца
• Формат обучения: модули с видеоуроками, лабораторные, работа с преподавателями
• Сертификат: сертификат установленного образца

Кому подойдет:

• начинающим и опытным разработчикам.

Преимущества:

• пожизненный доступ ко всем учебным материалам;
• бесплатный ознакомительный урок;
• выгодная стоимость обучения;
• налоговый вычет в размере 13% от оплаты;
• бесплатный переход между курсами;
• мини-курс по базовой IT-лексике на английском;
• карьерный интенсив для IT-специалистов.

Недостатки:

• иногда встречаются технические сбои.

Программа обучения:

• Основы работы с JavaScript
• Логические операторы и циклы в JavaScript
• Функции и методы в JavaScript
• Структуры данных в JavaScript
• Система модулей в JavaScript
• Введение в платформу Node.js
• Создание приложения-задачника на Node.js
• Разработка API со случайными данными на Express.js
• Создание Telegram-бота для техподдержки
• Углубленное изучение Node.js
• Завершающий модуль курса

Ознакомиться с полной программой >>>

Еще 8 дополнительных курсов Node.js

Если в основном рейтинге вы не нашли то, что искали — не переживайте. В подборке еще 8 курсов по Node.js на разные случаи жизни. Здесь есть программы с акцентом на enterprise-разработку, микросервисы или совмещение с другими технологиями. Такой выбор поможет подобрать вариант под карьерные цели.

• Node.js. Разработка серверов приложений и API от HTML Academy. На курсе студенты заглянут под капот Node.js и разберутся, как работает знаменитый цикл событий — поймут разницу между микро- и макрозадачами и научатся управлять асинхронным кодом. На практике освоят работу с файловой системой: будут читать и создавать файлы, обходить ограничения. Познакомятся с потоками (Streams) для генерации объемных данных и взаимодействия с внешними API.
• Node.js и Nest.js. Микросервисная архитектура от HTML Academy. В рамках курса студенты освоят интеграцию MongoDB и PostgreSQL с Nest.js, включая описание моделей, работу с Prisma ORM и реализацию паттерна «Репозиторий». Программа включает построение системы безопасности с JWT-аутентификацией, валидацией данных и использованием guards/pipes. Учащиеся изучат микросервисную архитектуру с RabbitMQ, паттерн BFF и отправку email-уведомлений. Завершится курс деплоем приложения через Docker с освоением продвинутых возможностей Nest.js для работы с файлами и обработки исключений.
• Node.js Серверный JavaScript от Loftschool. Всего за полтора месяца вы научитесь создавать серверные приложения любой сложности — от настройки скоростного обмена данными до деплоя на популярные платформы и серверного рендеринга. Вас ждет более 100 часов теории и практики в разных форматах, поддержка эксперта-наставника и реальные проекты для портфолио. После обучения останется бессрочный доступ ко всем материалам — сможете возвращаться к урокам в любой момент.
• Node JS разработчик от itProger. Обучение проходит в личном кабинете на онлайн-платформе с заданиями с моментальной автопроверкой, интерактивными тестами и работой над проектом. За два-четыре месяца студенты осваивают разработку приложений на Node с применением Express, MongoDB и сопутствующих технологий. Доступны четыре тарифных плана, предусмотрено выполнение дипломного проекта и оказывается помощь с трудоустройством.
• Node.js от JavaScript.ru. Этот курс — для разработчиков, которые уже знакомы с основами Node.js и хотят научиться создавать по-настоящему масштабируемые приложения. За шесть недель вы глубоко погрузитесь во фреймворк NestJS: разберетесь с внедрением зависимостей, научитесь грамотно управлять провайдерами и строить модульную архитектуру. На практике освоите современные подходы к маршрутизации и различным видам интеграций — от подключения баз данных до работы с внешними API.
• Node.js от Edwica. Этот курс — для JS-разработчиков, которые хотят прокачаться в бэкенде. За 10 интенсивных уроков вы с нуля освоите Node.js: поймете, как устроена платформа, научитесь создавать API на Express и работать с базами данных. Вы на практике разберетесь со встроенными модулями, чтобы уверенно писать серверные приложения.
• Серверное программирование на Node.js от Специалиста. Программа повышения квалификации объемом 36 академических часов рассматривает особенности работы на серверной JavaScript-платформе. Слушатели осваивают алгоритм установки и запуска платформы, работу с встроенными и внешними модулями, разработку приложений различного уровня сложности и масштаба.
• Node.js от Udemy. Видеокурс для программистов включает 172 лекции с практическими заданиями по внутреннему устройству Node. Изучается архитектура платформы, цикл событий и пул потоков, использование менеджера пакетов и фреймворка Express. По завершении обучения выдается сертификат.

Еще 10 дополнительных смежных курсов

Node.js редко работает в вакууме — ему нужны надежные помощники. В подборке из 10 смежных курсов собрали необходимое для комплексного развития: администрирование, тестирование, мониторинг приложений. Эти знания помогут не просто писать код, а вести проекты от идеи до продакшена.

• Fullstack-разработчик на JavaScript от Нетология. За 13 месяцев вы с нуля станете востребованным fullstack-разработчиком. Вы будете создавать живые сайты и приложения, освоите фронтенд и выберете бэкенд под свои интересы — мощный Node.js, универсальный Python или гибкий PHP. Ваше портфолио возрастет на 25 настоящих проектов, вы получите опыт на стажировке, диплом и мощную поддержку для старта карьеры.
• JavaScript от Skillbox. Всего за 3 месяца вы прокачаете JavaScript с нуля до уверенного уровня. Вас ждет настоящая кодерская закалка: больше 50 заданий на реальных примерах из практики. Неважно, новичок вы или хотите навести порядок в знаниях — научитесь работать с библиотеками, асинхронным кодом и сможете оживить любой сайт. Все материалы останутся с вами навсегда, а кураторы будут помогать на каждом шагу.
• Backend-разработчик на PHP от Skillfactory. За двенадцать месяцев вы с нуля освоите профессию backend-разработчика под руководством опытных экспертов. Программа включает освоение фронтенда и бэкенда, работу с языком запросов SQL, базами данных и платформой Docker. Вы получите навыки базового администрирования и работы с фреймворком Laravel, при этом 80% обучения составляет практика в различных форматах — от работы над проектами до участия в хакатонах. Карьерные специалисты помогут вам подготовиться к трудоустройству.
• Python-разработчик от Slurm. Всего за 4 месяца вы с нуля станете Python-разработчиком, даже если никогда не программировали. Научитесь создавать сайты на Django, работать с базами данных и Git, подключите внешние API. Опытные наставники помогут на каждом этапе, а в финале вы получите диплом, подтверждающий ваши новые навыки.
• Backend-разработчик от Loftschool. 12 недель — и вы бэкенд-разработчик на Node.js. Возьмете под контроль REST API, подружитесь с SQL и NoSQL базами, освоите WebSocket и безопасную аутентификацию. Соберете портфолио из 4 полноценных проектов с деплоем и получите бонус — основы PHP для универсальности.
• Backend-разработчик от Международной академии бизнеса IAB. Всего за 1-3 месяца вы получите 14 ключевых инструментов бэкенд-разработчика в арсенал. Освоите веб-программирование на PHP и JavaScript, научитесь управлять базами данных и защищать приложения. Выбирайте свой ритм — и вперед, к архитектуре профессионального уровня!
• JavaScript-разработчик от Nordic IT School. Курс для тех, кто уже знаком с основами веб-разработки. Четыре учебных блока охватывают ООП, Node.js, React и создание репозиториев. По каждой домашней работе вы получите персональное код-ревью от преподавателя, пополните портфолио несколькими проектами и получите возможность стажировки с консультациями по трудоустройству.
• Основы программирования на Java от Maxima. За восемь месяцев вы освоите популярный язык программирования для создания сервисов, веб-порталов и приложений для Android. Обучение проходит в небольших группах под руководством практикующих разработчиков, включает стажировки в IT-компаниях и завершается подготовкой к трудоустройству с пополнением портфолио новым проектом.
• Fullstack разработка от АНО Учебного центра "Трайтек". Пятидневный интенсив познакомит с актуальными возможностями JavaScript, фреймворками для создания интерфейсов и основами Node.js. Вы научитесь писать бэкенд для приложений, выполнять юнит-тесты и использовать сборщик модулей. По окончании выдается удостоверение о повышении квалификации.
• Node.js от beONmax. Практический курс познакомит с созданием серверной части приложений на Node.js с нуля. Вы освоите работу с базами данных и популярными фреймворками, отработав навыки на реальных примерах и проектах.

Бесплатные курсы Node.js

Если не готовы сразу платить за образование, начните с проверенных бесплатных материалов. Такие бесплатные курсы дадут понимание платформы. Они подойдут для обучения Node.js с нуля — помогут собрать первые проекты и разобраться с основами. Отличный способ начать карьеру в бэкенде без первоначальных вложений.

1. Учебник NodeJS от Code.mu. Занятия в текстовом формате созданы опытным айтишником, консультантом по веб-разработке. Подходит тем, кто уже освоил язык JavaScript. Вы узнаете, как работать с файловой системой с помощью встроенного модуля в синхронном и асинхронном вариантах, напишете и протестируете код, научитесь разворачивать статический сервер.
2. Node.js - курс по Node.js для начинающих от Bogdan Stashcuk. Содержательные уроки продолжительностью шесть часов от программиста и автора популярных курсов по разработке. Включает практические задания. Хороший старт для начинающих работу с Node. Половина программы занимает практика.
3. Node JS фундаментальный курс от А до Я. Node.js Теория и практика от Ulbi TV. В этом ролике вы разберете основные теоретические и практические моменты, связанные с Node.js. Сделаете небольшой фреймворк на системе, а также научитесь работать с базами данных. В конце вас ждет план на дальнейшее обучение.
4. Node JS - Быстрый курс за 1 час от Владилена Минина. Суперинтенсивное занятие позволит за час освоить основные аспекты применения Node. Обучение ведет фронтенд-разработчик с двенадцатилетним опытом работы. Видео отличается пошаговой демонстрацией процесса написания приложения, а также подробными объяснениями и рекомендациями эксперта.
5. NodeJS. Полный курс от WebDev. Вы создадите базовый роутинг на чистом Node.js, научитесь работать с динамичными данными с помощью шаблонизатора и напишете новостное приложение с поддержкой CRUD операций и хранением данных в MongoDB. В конце вы загрузите готовое приложение на Heroku.

Node.js продолжает доказывать эффективность в проектах — от стартапов до корпоративных систем. При выборе программы обратите внимание на баланс теории и практики: ищите курсы с проектами, а не только с теоретическими лекциями. Проверяйте, чтобы в программе имелись современные инструменты вроде Express.js, базы данных и основы DevOps. Не гонитесь за продолжительностью — иногда интенсив на 3-4 месяца даст больше, чем годовая программа. И помните, что проверенные курсы Node.js поддерживают связь с индустрией, приглашая действующих разработчиков и обновляя материалы по мере развития технологии.

А какие направления в разработке кажутся вам перспективными? Делитесь мнением в комментариях — обсудим, куда движется индустрия и на чем стоит сосредоточиться в обучении.

Главный итог — новая версия работает примерно на 27% быстрее, чем Python 3.13. Ключевое новшество — полноценная поддержка free-threading (многопоточности без глобальной блокировки GIL).

Как тестировали

В тестах участвовали версии CPython 3.9–3.14, а также PyPy 3.11, Node.js 24 и Rust 1.9.

Проверяли производительность на двух алгоритмах: рекурсивном вычислении чисел Фибоначчи и сортировке пузырьком. В однопоточном режиме Python 3.14 показал стабильный прогресс:

• В тесте Фибоначчи ускорение на 27% — 6,4 секунды против 8,2 секунд у версии 3.13.
• В сортировке пузырьком время сократилось до 2,05 секунды против 2,8 секунд.

Революция free-threading

Главный прорыв — free-threading, который наконец снимает системное ограничение GIL и раскрывает потенциал многоядерных процессоров.

В четырехпоточном тесте Фибоначчи скорость выросла в три раза, а в сортировке — в два раза относительно стандартной сборки.

Сравнение с другими

Стоит отметить, что PyPy 3.11 остается недосягаемым лидером — он быстрее CPython 3.14 почти в пять раз в рекурсии и в 18 раз при сортировке.

Node.js приблизился к PyPy в одном тесте, а Rust ожидаемо вырвался вперед — до 70 раз быстрее Python.

Что это значит

Python 3.14 — самая быстрая версия CPython на сегодня. Для проектов с интенсивными вычислениями free-threading дает ощутимый прирост. А вот JIT-режим пока остается экспериментальным — ускорения почти нет.

Если ваша команда может обновиться — это стоит сделать. Python 3.14 не просто быстрее: он впервые по-настоящему раскрывает многопоточность.

По его словам, система нарушает базовые принципы проектирования: объединяет все режимы рендеринга (SSR, CSR, SSG, ISR), но делает это «магическими» способами, из-за чего теряется ясность и усложняется поддержка.

Жесткая связность

Next.js строится на четырех опорах — CLI, компилятор, роутер и рантайм.

Но заменить или расширить любую часть почти невозможно: миграция с Webpack на Vite в одном из проектов заняла более полугода. Такая связность убивает гибкость и мешает инновациям.

Нет модульности

По словам Патила, Next.js не предоставляет плагинной архитектуры: даже простые интеграции проникают в кодовую базу и ломают абстракцию.

Проблемы есть и с переменными окружения — фреймворк смешивает их на этапе сборки и выполнения, что противоречит 12-Factor-принципам и мешает корпоративным пайплайнам.

Ограничения для бизнеса

Эксперт приводит реальные кейсы, где Next.js бессилен: динамическая смена тем в CRM, модульные платформы для разных команд, финансовые системы без пересборки Docker-образов, проекты с dual-licensing.

Во всех случаях фреймворк накладывал ограничения и мешал масштабированию.

Сложность убивает. Я выбираю простоту. Next.js — это удобный инструмент для быстрых проектов, но не фундамент для устойчивой архитектуры.

Инструкции с пометкой «простой гайд для новичков» часто оказываются квестом уровня «попробуй объяснить бабушке, как работает нейросеть». С непонятными терминами, шагами, пропущенными зависимостями и волшебными строками кода, которые «просто нужно вставить в Терминал».

Сначала вы запускаете Терминал и просто выполняете команду ajkl;gawgor;iqeg;iJLkqen. Потом идете в папку library/library/library/llibrary/liiiiiibrarrrary/llllliiiiibrary/hidden/hidden/hiding/you can’t find me...

К финалу автор доходит до заветного «Boop!» — метафоры магического момента, когда все вдруг начинает работать. Правда, путь до него оказывается настоящим марафоном с 193 Google-запросами, переполненной RAM и потерей самооценки.

Гайды не для тех, кто в первый раз

Автор подчеркивает, что уважает и благодарен тем, кто пишет туториалы. Но обращает внимание: большинство из них пишется с предположением, что читатель уже в теме, знает, как работает Терминал, что такое env и где искать .config на macOS.

В результате:

• «Простой трехшаговый гайд» занимает несколько часов.
• Пользователь оказывается в логической ловушке: чтобы понять туториал, нужно уже уметь делать то, чему он должен научить.
• Самые важные шаги часто опущены или неочевидны.

Реакция комьюнити: боль, смех и самопознание

Пост быстро разошелся по Reddit, Hacker News и X, где сотни пользователей делились похожими историями:

Я искал, как установить Pandas. Через 40 минут у меня был TensorFlow, Node.js и экзистенциальный кризис.

Каждый гайд заканчивается словами «все, теперь просто откройте Snarfus», а я сижу и думаю, кто такой вообще этот Snarfus?

Как делать гайды понятнее?

Несколько очевидных (но часто игнорируемых) советов авторам туториалов:

• Объясняйте, зачем делается каждый шаг. Не только «что», но и «почему».
• Проверяйте инструкции на чистой системе. Не у всех установлен Node 18, Homebrew и 19 глобальных пакетов.
• Избегайте внутреннего жаргона. Даже если вам кажется, что «shamrock portal» — общепринятый термин.
• Уточняйте зависимости и платформу. Команда, работающая на Ubuntu, может не работать на Windows.
• Добавляйте скриншоты. Иногда визуальный шаг говорит больше, чем 10 строк текста.

Главные отличия Web3 от Web2

Перед тем как углубиться в код и практику, полезно увидеть основные различия между привычной Web2-разработкой и новой логикой Web3.

Представим себе простой сервис для задач. В классическом Web2 его работа привычна: сервер обрабатывает запросы, база данных хранит задачи, а пользователь авторизуется через почту и пароль. Всё централизовано и зависит от владельца сервера.

В Web3 логика сильно меняется. Пользователь входит в систему с помощью криптокошелька, например, MetaMask. Каждая задача создаётся транзакцией и записывается в смарт‑контракт, а значит становится частью блокчейна. Удалить её уже нельзя — только отметить статус выполнения. Такой подход даёт прозрачность: любой участник сети может проверить, что задача действительно существует, и её статус изменён честно.

Стек Web3: что понадобится на практике

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

• Блокчейн: Ethereum, Layer‑2 (Arbitrum, Optimism, Base, Polygon), Solana.
• Языки: Solidity (EVM), Rust (Solana), Go (инфраструктура и сервисы).
• Библиотеки: ethers.js, wagmi.
• Фреймворки: Hardhat, Foundry, Truffle.
• Хранилища: IPFS/Arweave для файлов и метаданных.
• Кошельки/подключение: MetaMask, WalletConnect (v2/WalletConnect Network), Web3Auth.

Точка входа для новичка — Alchemy, а также ethers.js.

Пример. Быстрое подключение кошелька (ethers.js).

Архитектура DApp: из чего состоит современное Web3‑приложение

Любое Web3‑приложение строится из нескольких слоёв, каждый со своей ролью. Фронтенд остаётся привычным SPA, но работает не с сервером, а напрямую с кошельком и смарт-контрактами. Контракты содержат бизнес‑логику и хранят ссылки на данные в децентрализованных хранилищах. Оракулы обеспечивают связь с внешним миром, например, передают цены или сообщения между разными блокчейнами. Важную часть играет off‑chain слой — сервисы вне блокчейна (индексаторы, аналитика), которые помогают быстрее искать и обрабатывать данные, при этом не перегружать сеть.

Пример. Возьмём DeFi‑приложение. Пользователь открывает фронтенд и инициирует операцию swap(). В ответ фронтенд обращается к смарт‑контракту, который выполняет обмен токенов. Чтобы определить курс, контракт тянет актуальные данные через оракул. При этом тяжёлые артефакты, изображения или отчёты не хранятся в блокчейне напрямую — они лежат в IPFS. Сам контракт содержит только контент‑идентификаторы CID. Таким образом, получаем баланс: блокчейн отвечает за логику и безопасность, а децентрализованное хранилище — за данные.

Практика: ваш первый DApp за вечер

Давайте попробуем собрать простейшее приложение своими руками.

Шаг 0. Подготовка

Сначала убедитесь, что у вас стоит Node.js LTS и Git. Также нужен браузер с установленным MetaMask, где можно создать тестовый аккаунт. Чтобы оплачивать транзакции в тестовой сети, заранее возьмите немного тестовых монет через faucet — например, для Sepolia или Polygon Amoy.

Шаг 1. Проект

Создадим новый проект и установим Hardhat вместе с тулзами. Эта среда нужна для компиляции и деплоя контрактов.

Шаг 2. Контракт

В папке contracts/ создаём файл TaskTracker.sol и копируем туда код смарт-контракта из первого раздела. Это и будет бизнес-логика нашего приложения.

Шаг 3. Сценарий деплоя

Пишем скрипт, который разворачивает контракт в сети. Это простой скрипт на JavaScript, который вызывает методы Hardhat.

Шаг 4. Конфиг сети

В файле hardhat.config.js добавляем настройки для подключения к тестовой сети. Используем RPC-URL от Alchemy или Infura и приватный ключ от тестового аккаунта — его можно экспортировать из MetaMask, но использовать только для тестовой сети.

Шаг 5. Деплой в тестнет

Теперь запускаем скрипт деплоя. После выполнения увидите адрес контракта — он понадобится для фронтенда.

Шаг 6. Фронтенд (React + ethers.js + wagmi)

Собираем простое SPA: форма, чтобы добавить задачи, и кнопка «complete». Здесь мы используем ethers.js для обращения к контракту. Сделайте вызовы addTask и completeTask.

Подводные камни Web3-разработки и что с ними делать

Комиссии (gas): любая запись в блокчейн стоит денег и иногда комиссия выше ценности операции — например, $10 за простую задачу.

• Что делать: использовать Layer-2 (Arbitrum/Optimism/Base/Polygon), выбирать сети с низкими комиссиями (Solana, Avalanche), оптимизировать контракты и батчи транзакций.

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

• Что делать: показывать «оптимистичный UI», кешировать данные, переносить часть логики off-chain, использовать быстрые сети (Solana, Near, Aptos).

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

• Что делать: проходить аудит (CertiK, Trail of Bits), использовать проверенные библиотеки (OpenZeppelin), писать тесты в тестовых сетях (Goerli, Sepolia), внедрять баг-баунти и ролевую модель доступа.
• Ресурс: ConsenSys Diligence — Smart Contract Security Best Practices.

UX: вход через кошелёк сложнее привычного логина/пароля. Нужно ставить расширение, пополнять баланс и подтверждать каждую транзакцию.

• Что делать: использовать аккаунт-абстракцию (ERC-4337), социальный логин, gasless транзакции через Paymaster, улучшать UI (подсказки, авто-фокус на MetaMask).

Регуляция: законы о Web3 пока разные в каждой стране. Легальное в одной юрисдикции может быть запрещено в другой (например, токенизация акций без лицензии).

• Что делать: консультироваться с юристами, следить за изменениями. Например, MiCA в ЕС — “Markets in Crypto-Assets Regulation” — это единый регламент по криптоактивам в Евросоюзе.

Безопасность всегда должна быть на первом месте, потому что в Web3 есть риск потерять реальные деньги пользователей.

Карьерные возможности и перспективы

Web3‑разработчиков уже активно ищут: зарплаты в среднем предлагают выше, чем у Web2‑коллег. Кроме программистов, востребованы смежные роли: аудиторы смарт‑контрактов, специалисты по безопасности, а также продакт‑менеджеры и аналитики, которые понимают специфику блокчейна.

Чтобы войти в профессию, начните с изучения Solidity и базовых паттернов смарт‑контрактов. Сделайте пару пет‑проектов и выложите код в GitHub. Отличный вариант прокачки — участвовать в хакатонах и грантовых программах от Ethereum Foundation или Solana Grants. Это даёт и опыт, и контакты, и иногда финансирование.

Пара пет‑проектов + понимание блокчейна — хороший старт в Web3‑команду.

Будущее Web3

Web3 не вытеснит Web2 полностью, но поменяет привычный подход к разработке. Разработчику это открывает новые вызовы: комиссии, безопасность и UX, но одновременно и новые возможности — прозрачные данные, токенизация, децентрализованные бизнес‑модели.

Для тех, кто только входит в сферу, это шанс попасть в индустрию на раннем этапе и быстро нарастить экспертизу. Простые пет‑проекты, хакатоны и знакомство с инструментами дают ощутимый старт.

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

Дмитрий Борцов — руководитель разработки клиентских интерфейсов в PREMIER.ONE. В его подчинении более 60 инженеров, распределённых между вебом, Android, iOS и SmartTV. В индустрии он уже 15 лет: прошёл путь от фриланса и собственной студии до руководства крупными командами. Такой опыт, как он сам говорит, позволяет видеть рынок «с двух сторон» — понимать, что нужно бизнесу и какие компетенции позволяют разработчику стоить дороже. Сегодня Дмитрий совмещает управленческую роль с менторством: вместе с техлидом PREMIER.ONE Андреем Автушенко он развивает платформу Frontend Alliance, где в формате парного наставничества помогает фронтендерам — от джунов до тимлидов — прокачивать хард и софт скиллы, готовиться к собеседованиям и строить карьеру с опорой на реальную практику.

Фронтенд под давлением: рынок стал жёстче, но не умер

Сегодня фронтенд-разработчикам всё чаще приходится отвечать на вопрос: «А рынок-то живой или всё?» Картинка действительно изменилась. Ещё несколько лет назад компании практиковали агрессивный найм: быстро расширяли команды, нанимали десятки разработчиков сразу, а через полгода без сожалений сокращали половину штата. Это было дорого, но при низкой ключевой ставке позволительно: деньги горели, но продукт успевал расти.

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

Тем не менее, говорить о «смерти» фронтенда было бы ошибкой. Спрос не исчез, он просто сузился до тех, кто способен приносить реальную ценность. И здесь проявляется давний раскол: 95% специалистов ограничиваются задачами уровня интерфейсной косметики, а оставшиеся 5% умеют проектировать системы, предлагать архитектурные решения и смотреть шире макета. Именно за этих людей компании будут бороться при любых условиях.

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

Что должен уметь фронтендер в 2025 году и как попасть в «5% из 95»

Уровень middle и senior во фронтенде больше не определяется знанием пары фреймворков. Базовый «джентльменский набор» очевиден: HTML, CSS, JavaScript и хотя бы один современный фреймворк — React, Vue, Angular или Svelte. Сегодня к нему де-факто добавился TypeScript: без него в резюме вы рискуете выглядеть устаревшими, даже если на проекте TS практически не используется. Работодатели хотят видеть уверенную работу с ним, потому что это напрямую ассоциируется со стабильностью и предсказуемостью кода.

Дальше идут надстройки, которые начинают выделять кандидата. Это метафреймворки вроде Next.js или альтернативы с упором на SSR и SSG, понимание разных паттернов рендера и умение применять их под конкретный продукт. Сюда же — юнит-тесты. Никто не будет устраивать экзамен на знание Jest, но сам факт владения тестированием сразу повышает ценность инженера.

Самый заметный маркер — архитектурные практики. Фронтендер, который мыслит архитектурно, понимает FSD, может объяснить, зачем нужны микрофронты (и когда они не нужны), сразу выделяется на фоне тех, кто «просто собирает фичи». Настроить приложение так, чтобы через два года его не пришлось переписывать, — это компетенция, которая превращает разработчика в дорогого специалиста.

При этом стек сам по себе не делает из мидла сеньора. Настоящее отличие — в мышлении. Сеньор умеет общаться с соседними командами, отстаивать нужные изменения в API или инфраструктуре, учитывать долгосрочные риски продукта. Это опыт, который не заменят ни курсы, ни туториалы. И именно он отличает того, кто «пишет код», от того, кто создаёт систему.

Найм и подготовка кандидата: где спотыкаются фронтендеры

Первое, что бросается в глаза при просмотре резюме фронтендеров, — это ошибки самопрезентации. Человек может написать «переписал приложение на новый фреймворк» и не уточнить, что это сократило время загрузки на 30% или сняло половину багов в проде. Для HR выглядит как рядовая строчка, хотя на деле это серьёзное достижение. Добавим сюда непонимание того, как работает HeadHunter: большинство кандидатов просто игнорируют логику поиска и фильтров, и их резюме тонет в выдаче. В итоге, 85% проблем — это не недостаток скиллов, а то, как они упакованы.

Работа ментора начинается именно с этого: помочь собрать рабочее резюме и научить играть по правилам площадок. Но это лишь малая часть. Основная работа — скорректировать харды и софты, довести знания до актуального уровня, натренировать коммуникацию. Ведь первое собеседование с HR часто решает, попадёте ли вы вообще на технический этап. Поэтому вместе с резюме разбирается поведение: как отвечать рекрутеру, какие вопросы задавать, как «продавить» интерес к себе.

Типичный план менторской работы занимает от двух до шести недель у специалистов с опытом — если задача ограничивается «освежить знания и подтянуть резюме». Для выпускников массовых онлайн-курсов это уже четыре месяца и больше: приходится достраивать базу, убирать пробелы, переучивать. У новичков срок может растянуться до полугода и дальше, и тут всё зависит от предрасположенности к стеку и дисциплины.

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

Кейс «Кода найма»: как Ярослав Грачёв выбил оффер в 380К

Когда к Дмитрию обратился Ярослав, сразу стало ясно: этот кандидат будет работать до конца. Мотивация была жёсткой — беременная жена, переезд в Москву, ипотека. На первом звонке ментор проверил главное: что Ярослав не «красит кнопки», а действительно решает задачи. Этого хватило, чтобы выстроить доверие и составить план.

Первое, что пришлось менять, — резюме. Вместо сухого «работал три года» появилось описание проектов и секция «Обо мне». Ярослав даже перефотографировался, чтобы профиль выглядел живым. Параллельно он учился работать с алгоритмами HeadHunter и GPT: HH поднимал резюме в выдаче, а бот имитировал собеседования. Через две недели у кандидата уже был первый оффер.

Ситуация была интересной: предложение на 300 тысяч выглядело заманчиво, но ментор настоял не торопиться. Аргументы были простыми: поток откликов и приглашений уже пошёл, значит, офферы будут и дальше. Они вместе придумали безопасную отговорку для HR и договорились ждать неделю. Ставка сыграла — скоро пришёл новый оффер на 360 тысяч.

И тут началась работа с переговорами. Дмитрий считал, что Ярослав стоит дороже, и предложил сыграть на личных обстоятельствах: «Переезд, ипотека, второй ребёнок — дайте больше». Обычно такой прямолинейный запрос не работает, но в этот раз HR пошёл навстречу и поднял ставку ещё на 20 тысяч. Сработало сочетание доверительной коммуникации и того, что за спиной у кандидата был запасной оффер.

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

А дальше начинается игра на рынке: один оффер на 250 можно держать как «аварийный», второй на 300 использовать для торга, третий — поднять до 350. Главное — не зажиматься на звонках с HR: «их мотивация — провести тебя дальше, деньги они получают за закрытых кандидатов», — напоминает Дмитрий. Поэтому правило простое: дружелюбие, открытость и готовность разговаривать.

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

Советы начинающим фронтендерам

Дмитрий выделяет несколько аспектов, которым стоит уделять внимание в вопросе оффера мечты:

Не рассчитывайте только на ментора

Ментор может сильно ускорить путь: кто-то готовит к собесам, кто-то учит реально работать. Но это не панацея. Без самостоятельного копания в YouTube, статьях и пет-проектах вы просто застрянете. При этом нужно быть готовым к тому, что половина выученного окажется невостребованной, а рынок попросит ещё десяток дополнительных технологий.

Начинайте с основы, а не с фреймворка

Ключевой навык фронтендера — JavaScript. «Все есть JavaScript», — как сказал Илья Климов. React, Vue, Angular, Svelte — это лишь надстройки. Если понимаете сам язык и то, как он работает под капотом, вы сможете писать на чем угодно, хоть в фронте, хоть на Node.js в бэке.

Не ведитесь на быстрые рецепты успеха

Онлайн-школы и ютуберы любят обещать: «выучишь React — и всё в шоколаде». Но без знания JS никакой React не спасёт. На собеседованиях почти всегда спрашивают именно JavaScript, а не то, как вы намагичили интерфейс на очередном фреймворке.

Думайте о том, зачем работает код

Фронтендер, который просто копирует чужие решения, быстро упирается в потолок. Важно не только знать синтаксис, но и понимать, зачем язык ведёт себя именно так. Это отличает разработчика, который просто «собирает интерфейсы», от того, кто способен решать реальные задачи.

История Дмитрия Борцова и Ярослава Грачёва — это иллюстрация того, что даже в перегретом и избирательном рынке фронтенда можно найти своё место. Ключ к успеху — не только в технической базе, но и в умении правильно упаковать опыт, показать насмотренность и держать фокус на том, что важно работодателю. Для джунов это часто означает вложиться в JavaScript, а не в очередной модный фреймворк. Для мидлов и выше — развивать софты и стратегически подходить к собеседованиям. А для всех уровней — не замыкаться в одиночном обучении, а искать наставников и сообщество, которые помогают расти быстрее.

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

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

1. ИХЦ (Интернет ХостингЦентр): конфигурации под нагрузку с NVMe, CPU до 5 ГГц и трафиком без ограничений

Один из самых гибких по конфигурациям хостеров в обзоре. Работает с 2009 года. Поддерживает разные типы виртуализации (KVM и Virtuozzo), предлагает линейки с SSD и NVMe, российские и европейские площадки, разные уровни мощности — от базовых до высоконагруженных.

Линейки VPS и конфигурации

1. ssdVPS — базовая линейка для России. Позволяет собирать конфигурации от 1 до 32 ГБ оперативной памяти, от 1 до 10 виртуальных CPU и от 20 до 300 ГБ SSD-диска.
2. NVMe/ — линейка на базе KVM с более высокой производительностью ввода-вывода. Доступны конфигурации от 1 до 24 ГБ RAM, от 1 до 12 vCPU, SSD от 15 до 300 ГБ.
3. EU-NVMe/ — аналог NVMe-линейки, но размещённый в Амстердаме. Конфигурации расширены: от 1 до 64 ГБ оперативной памяти, от 1 до 18 CPU, от 15 до 1000 ГБ SSD, скорость порта — от 200 до 500 Мбит/с.
4. VPS 5 ГГц — отдельная линейка на KVM, ориентированная на проекты с высокой частотной нагрузкой, до 5 ГГц на ядро, порт до 1000 Мбит/с.

VPS Windows — выделенная категория для задач на Windows.

Особенности и инфраструктура

В ИХЦ можно выбрать между двумя видами виртуализации: KVM и Virtuozzo. Виртуализация KVM подходит для задач, где нужна изоляция ресурсов, стабильность под нагрузкой и совместимость с Linux и Windows. Virtuozzo — более экономный вариант с быстрой настройкой, но с возможной перераспределённой нагрузкой между соседними VPS.

Связь с поддержкой доступна через тикеты, онлайн-чат на сайте, телеграм-бота, телефон и сообщения ВКонтакте. Поддержка работает 24/7. На всех тарифах включена базовая DDoS-защита.

Примеры использования VPS от IHC

Компания предоставляет конкретные кейсы. Примеры:

• Проект 1: VPS NVMe/24 (24 ГБ RAM, ~200 ГБ SSD) используется под бэкенд iOS-приложения. Стек: nginx, PHP, MySQL. Нагрузка: 12 000 уникальных пользователей в сутки. Утилизация CPU — 25%.
• Проект 2: VPS NVMe/12 (12 ГБ RAM, ~120 ГБ SSD) для развлекательного сайта. Стек: nginx, Docker, Node.js. Нагрузка: 7 000 уникальных пользователей в сутки, загрузка CPU — около 20%.

Серверы стабильно держат среднюю и высокую нагрузку — даже с трафиком в 10–12 тысяч пользователей в сутки остаётся запас по ресурсам.

Дополнительные опции

ИХЦ предлагает тестовый период в 3 дня, безлимитный трафик, бесплатный первый месяц ispmanager 6 в подарок, а также предустановку панелей управления (ispmanager, FastPanel) или VPN-шаблонов по выбору при заказе. Также доступны бэкапы, SLA и автоснапшоты.

Цены

Что касается ценовой политики, стоимость VPS в России (линейка «ssdVPS») начинается от 380 руб/мес или 3800 руб/год (12 месяцев по цене 10). Европейские VPS («EU-NVMe/») и VPS на KVM («NVMe/») стартуют от 440 руб/мес или 4400 руб/год, а каждый дополнительный гигабайт памяти стоит 6 рублей.

2. FirstVDS: мощные VDS на AMD EPYC и Ryzen

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Есть VPS для разных сценариев нагрузки — от стандартных сайтов до тяжёлых веб-приложений и проектов с высокими требованиями к CPU и отказоустойчивости. Отдельные решения для Битрикс, установка ОС семейства Linux, FreeBSD и Windows Server.

Линейки VPS: от базовой мощности до кластера Ceph

FirstVDS предлагает три основные линейки, которые отличаются архитектурой и назначением:

1. VDS Форсаж — гибкая конфигурация сервера на базе AMD EPYC, до 128 ядер (до 3,7 ГГц), до 512 Гб оперативной памяти и до 4 000 Гб быстрого NVMe-накопителя. Локации Москва и Амстердам. Стартовая стоимость такой конфигурации составляет от 749 руб/мес.
2. Для нагруженных проектов — CPU.Турбо — гибкая конфигурация сервера на базе AMD Ryzen с частотой до 5,7 ГГц, DDR5 и с быстрыми NVMe-накопителями. Идеально для Битрикс. Локация Москва. Начальная цена CPU.Турбо — от 624 руб/мес. При покупке лицензии Битрикс (1С-Битрикс: Управление сайтом или Битрикс24) есть дополнительная скидка 30% на 3 месяца аренды этого тарифа.
3. Отказоустойчивый VDS Атлант — гибкая конфигурация сервера на базе AMD EPYC — до 192 ядер (до 3,5 ГГц), до 768 Гб оперативной памяти и до 8 Тб быстрого NVMe-накопителя. Репликация данных между узлами кластера Ceph и дублирование сетевого оборудования. Локация Москва. Его стартовая стоимость от 1619 руб/мес, при этом бесплатные автобэкапы уже включены.

Компания использует два центра обработки данных в Москве: IXcellerate (уровень Tier III) и Web DC. Для тарифа Форсаж и готовых тарифов также доступен ЦОД euNetworks (уровень Tier III) в Амстердаме.

Сетевые возможности, трафик и безопасность

В стоимость каждого сервера входит бесплатный выделенный IP-адрес. Клиенты могут выбрать между 100 Мбит/с с безлимитным трафиком или портом 1 Гбит/с с включёнными 32 Тб трафика.

Защита от DDoS-атак и система безопасности BitNinja для сервера и сайта доступны как подключаемые опции. Также предоставляются объектное хранилище S3, автобэкапы и Кибер-бэкап. Для безопасности коммуникаций используются SSL-сертификаты GlobalSign.

Управление, ПО и поддержка

При заказе сервера клиент получает лицензию ispmanager 6  lite: первый месяц панель предоставляется бесплатно, дальше оплачивается по тарифу самой панели. Предлагается гибкий выбор операционных систем, включая Linux, FreeBSD и Windows Server. Под разовые задачи доступны готовые рецепты установки — от Битрикс и GitLab до TeamSpeak, LAMP‑стека и других популярных наборов ПО.

Для установки и решения любых вопросов — доступна живая круглосуточная техническая поддержка 24/7 через чат на сайте, в личном кабинете и по телефону, без использования чат-ботов. Для самостоятельного решения вопросов предусмотрена обширная база знаний.

Клиентские бонусы и программы

Есть тестовый период до 3 дней. Регулярно проводятся акции и предоставляются скидки, в том числе на тарифы для нагруженных проектов.

1) При переходе от другого хостера FirstVDS бесплатно переносит до 10 сайтов. Дополнительно предоставляется скидка 40% на первый месяц аренды VPS при оплате сервера на 1, 3 или 6 месяцев, либо 3 месяца бесплатной аренды VPS при оплате на год.

2) Клиенты с возрастом аккаунта от 5 лет получают постоянную скидку на аренду VPS, начиная от 5% и увеличиваясь ежегодно до 20%.

3) Действует реферальная программа, по которой партнёр получает 10% от расходов привлечённых клиентов, а привлечённый пользователь — скидку 25% на первый месяц аренды VPS.

4) Стоимость продления домена у FirstVDS равна актуальной стоимости его регистрации.

3. InCloud: VPS‑площадки для бизнеса, где важен SLA

InCloud продаёт виртуальные серверы, работающие в отказоустойчивом кластере на базе enterprise хранилищ NetApp и HPE 3PAR. Позиционируется как решение для 1С, малого/среднего бизнеса и аутсорс компаний, которым нужны предсказуемые ресурсы и техподдержка профессиональных инженеров, а не чат‑ботов.

Тарифные планы и ценообразование

InCloud предлагает две основные линейки тарифов:

1. Стандартный тариф: внутри процессоры Intel Xeon 2600v4 2ГГц и оперативная память DDR4 2400 МГц.Стоимость: 1 CPU – 200 рублей, 1 Гб RAM – 200 рублей.
2. Производительный тариф: использует процессоры AMD EPYC до 3.8 ГГц и оперативной памяти DDR5 4800 МГц. Стоимость: 1 CPU – 250 рублей, 1 Гб RAM – 250 рублей.

Стоимость дискового пространства: SATA диски: 3 рубля за 1 Гб. SSD и NVMe диски: 13 рублей за 1 Гб.

Архитектура и поддержка

Теперь про то, что упрощает жизнь и добавляет надежности нашим развернутым сервисам:

• Ежедневные бэкапы: данные ваших серверов будут копироваться каждый день, и храниться они могут до 30 дней.
• Удобная панель управления: через нее можно делать снапшоты и клонировать серверы. Для разработчиков это просто золото – быстро накатить тестовую среду, попробовать новую фичу, а потом откатиться или создать идентичные рабочие среды.
• SLA-договор: есть возможность заключить SLA-договор, чтобы получить гарантированный уровень доступности услуг.
• Новейшие мощные серверы — на базе AMD EPYC 4 поколения.

Одна из фишек – это возможность напрямую проконсультироваться с сертифицированными инженерами InCloud по сложным проектам.

А что с клиентскими кейсами

1. Кейс Vamkamin: производственная компания, которая ускорила работу своей системы 1С и сократила IT-расходы на 35%. У них была проблема с медленной работой 1С при одновременном доступе бухгалтерии, склада и отдела продаж, а также с частыми простоями на локальных серверах. InCloud предложил перенести все сервисы в облако, используя серверы на базе AMD EPYC 9554, что обеспечило прирост производительности более 40% по сравнению с предыдущими решениями. Также были внедрены гибкое масштабирование ресурсов и ежедневное резервное копирование.
2. Кейс Веб-студии 100UP: компания занимается разработкой и поддержкой сайтов для крупных торговых сетей и e-commerce проектов. 100UP переехала к облачному провайдеру InCloud, выбрав тарифы на базе AMD EPYC 9554 с высокой тактовой частотой и большим количеством ядер. Благодаря разнообразию тарифов команда легко распределила проекты по нужным по производительности виртуальным серверам. После переезда 100UP смогла сократить время отклика клиентских сайтов в среднем на 45%, обеспечить бесперебойную работу даже в периоды высокой сезонной нагрузки, ускорить запуск новых проектов, фокусироваться на разработке и маркетинге и улучшить качество предоставляемых услуг.

4. SmartApe: быстрые VPS на NVMe‑SSD

SmartApe подойдет проектам, где дисковая подсистема и CPU работают без простоя: интернет‑магазины, порталы с большим количеством контента, внутренние корпоративные системы, высоконагруженные API. Если нужен быстрый старт — сервер создаётся за одну‑две минуты; если понадобится масштабирование, тариф можно увеличить без миграции.

Преимущества этих VPS

Используются современные серверные NVMe SSD диски в RAID массиве, которые в 600 раз быстрее обычных HDD. Скорость чтения достигает 8000 Мбайт/с, а записи — 2000 Мбайт/с.

Серверы работают на мощных процессорах Intel Xeon Gold или AMD EPYC (до 3.7 ГГц) и быстрой памятью DDR4. Используется полноценная виртуализация KVM с выделенными ресурсами для гарантии их предоставление. Дата-центры уровня TIER-III и TIER-IV обеспечивают Uptime 99.982%. Данные хранятся в хранилище RAID-10.

Дополнительно клиенты получают полный root-доступ (по SSH для Linux и RDP для Windows), возможность установки любых операционных систем (более 20, включая Ubuntu, CentOS, Debian, Windows Server) и ПО, а также полную изоляцию от других клиентов.

Удобство и поддержка

• Бесплатная панель управления (Hestia) или платная ISPmanager для простого управления сервером.
• Бесплатное базовое администрирование и помощь в переносе сайтов.
• Круглосуточная квалифицированная поддержка 24/7.
• Бесплатный тестовый период 10 дней без оплаты и ввода карты.
• Защита от DDoS-атак включена в стоимость.
• Выделенный внешний IP-адрес (возможность купить до 10 IP).

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

Пример использования: интернет‑магазин

VPS c 2 vCPU, 4 ГБ RAM, 80 ГБ SSD и портом 100 Мбит/с; при обычном трафике сайт обслуживает 300–500 уникальных посетителей в день, одновременно на страницах бывает 10–20 человек, а в пиковую распродажу до 50; средняя нагрузка 5–10 запросов в секунду, короткими всплесками до 20; заявленный аптайм 99,982 %, реальные замеры отклика после кэширования — 200–300 мс; счёт за такой сервер выходит около 1 300 рублей в месяц.

Пример использования: API на Node.js

4 vCPU, 8 ГБ RAM, 160 ГБ NVMe и канал 200 Мбит/с; сервис стабильно обрабатывает 50–100 запросов в секунду, на пике достигает 200, одновременно подключены 500–1 000 клиентов, максимум 2 500; трафик близок к 200 ГБ в месяц; при том же аптайме 99,982 % средняя задержка ответа укладывается в 50–100 мс; ежемесячная стоимость в зависимости от опций колеблется в диапазоне 2 600–3 000 рублей.

SmartApe имеет смысл брать, когда дисковая скорость и гарантированные ресурсы важнее высокого GUI и почасовой тарификации, для расчёта стоимости есть калькулятор конфигураций на сайте и оперативная техподдержка.

5. PSB Hosting: что даёт их VPS‑платформа

PSB Hosting продвигает VPS-хостинг как решение для сайтов, приложений и SaaS-сервисов, которым нужна предсказуемая мощность и высокий SLA. Провайдер делает упор на новое оборудование, пропускную способность без ограничений и инфраструктуру уровня Tier III+.

Локации и тарификация

Серверы разворачиваются в четырёх точках: Нидерланды, США, Германия и Финляндия. Для каждой площадки доступен одинаковый конструктор конфигураций. Базовый план NL‑100, который включает 1 vCPU, 2 ГБ RAM и 30 ГБ SSD, стоит 6 долларов в месяц. Линейка поднимается ступенчато:

Слайдеры позволяют довести параметры до 32 ядер, 64 ГБ RAM и 510 ГБ SSD; верхняя планка оплаты — 220 $ в месяц.

Трафик безлимитный на любых конфигурациях — дополнительной оплаты за гигабайты нет.

Аппаратная платформа, ОС и предустановки

В хост-узлах применяются процессоры последних линеек AMD и Intel. Оперативная память — DDR5, что снижает задержки при обращении к ОЗУ. Дисковая подсистема полностью на NVMe, объединена в RAID 10: чтение и запись выше, чем у классических SSD, а отказ одного накопителя не выводит хранилище из строя. К каждому VPS подключён выделенный канал с пропускной способностью до 10 Гбит/с.

Сервер можно поднять сразу с Windows Server, Ubuntu, Debian, CentOS или FreeBSD. Для быстрого старта доступны готовые образы: Bitrix, Django-стек, Docker, FastPanel, Hestia CP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, Vesta CP и другие.

Управление и поддержка

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

Как выбрать VPS под свой проект

Для сайта с пиковыми нагрузками подойдёт SmartApe, где дисковая подсистема на NVMe-SSD в RAID-10 обеспечивает скорость чтения до 8000 Мбайт/с и записи до 2000 Мбайт/с, а сайт на конфигурации с 2 vCPU, 4 ГБ RAM и 80 ГБ SSD выдерживает 300–500 уникальных посетителей в день с пиком до 50 одновременных пользователей и нагрузкой 5–10 запросов в секунду (короткими всплесками до 20).

Если проект включает высоконагруженный API, например, на Node.js, то оптимален SmartApe с конфигурацией 4 vCPU, 8 ГБ RAM и 160 ГБ NVMe, которая стабильно обрабатывает 50–100 запросов в секунду (пики до 200) при 500–1000 одновременных подключениях (максимум 2500) и трафике до 200 ГБ в месяц.

Для задач с 1С, где важна стабильность и сокращение IT-расходов, выбирайте InCloud на базе AMD EPYC 9554: в кейсе Vamkamin это ускорило работу системы на 40%, сократило расходы на 35% и минимизировало простои, с ежедневными бэкапами до 30 дней и SLA-договором.

Если нужен VPS для Битрикс с высокой частотой CPU, подойдёт FirstVDS на AMD Ryzen (CPU.Турбо) с частотой до 5,7 ГГц и DDR5: скидка 30% на 3 месяца при покупке лицензии Битрикс, плюс отказоустойчивость на кластере Ceph с репликацией данных.

Для веб-студий с разработкой и поддержкой сайтов для e-commerce, где требуется распределение проектов по производительности и бесперебойная работа в сезонные пики, подойдёт InCloud на AMD EPYC 9554: в кейсе 100UP это сократило время отклика на 45% и обеспечило стабильность под высокой нагрузкой.

Если проект ориентирован на международный трафик с предсказуемыми ресурсами и высоким SLA, выбирайте PSB Hosting с локациями в Нидерландах, США, Германии или Финляндии, безлимитным трафиком и каналом до 10 Гбит/с на DDR5 и NVMe в RAID 10.

Для бэкенда мобильного приложения с нагрузкой до 12 000 уникальных пользователей в сутки (утилизация CPU 25%) подойдёт ИХЦ на NVMe/24 с 24 ГБ RAM и ~200 ГБ SSD, стеком nginx, PHP, MySQL.

Если развлекательный сайт с более чем 5000 уникальных пользователей в сутки (загрузка CPU ~20%), то подходит ИХЦ на NVMe/12 с 12 ГБ RAM и ~120 ГБ SSD, стеком nginx, Docker, Node.js. Он обеспечит стабильность с безлимитным трафиком и DDoS-защитой.

Выбор сводится к трём вопросам: где ваши
пользователи, какую пиковую нагрузку вы ждёте и нужен ли формальный SLA.
Сформулируйте эти требования заранее — и любой из пяти хостингов закроет задачу
без проблем в продакшне. Добавить свои рекомендации VPS хостингов — вы всегда
можете в комментариях, желательно описывать короткие кейсы.

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

Посмотрим, кто из них есть в этом списке, и определим особенности хостингов для сайта.

1. FirstVDS: профессиональные решения для любых проектов

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Хостинг подойдет бизнесу любого масштаба: для любых сайтов — от визиток до высоконагруженных интернет-магазинов, для разработки и тестирования, для сервисов и других проектов. Отдельные решения для Битрикс, установка ОС семейства Linux и Windows Server.

Особенности хостинга

Надёжность

FirstVDS обеспечивает аптайм 99,97–99,99% в 2025 году, подтверждённый замерами (например, отклик из Москвы — 27 мс в апреле 2025). Серверы размещены в трёх дата-центрах уровня Tier III: два в Москве (IXcellerate и Web DC) и один в Амстердаме (euNetworks). Отказоустойчивый кластер Ceph гарантирует работу даже при сбоях точки или канала.

Инфраструктура

Серверы работают на процессорах Intel Xeon и AMD EPYC (до 5,7 ГГц в линейке CPU.Турбо), с быстрыми NVMe-дисками объёмом до 8 ТБ и оперативной памятью DDR5 (до 768 ГБ в VDS Атлант). Это обеспечивает высокую производительность для ресурсоёмких задач, таких как Битрикс или высоконагруженные приложения.

Гибкость

Тарифы масштабируются: от базовых конфигураций (1 CPU, 1 ГБ RAM, 40 ГБ SSD) до мощных серверов (192 ядра, 768 ГБ RAM, 8 ТБ NVMe). Линейки:

• VDS Форсаж: AMD EPYC, до 128 ядер, 512 ГБ RAM, 4 ТБ NVMe, от 749 ₽/мес (Москва/Амстердам).
• CPU.Турбо: AMD Ryzen до 5,7 ГГц, DDR5, от 624 ₽/мес (Москва).
• VDS Атлант: отказоустойчивый, до 192 ядер, 8 ТБ NVMe, от 1619 ₽/мес (Москва).
• VDS Storage: хранилище, от 704 ₽/мес (Москва).Горячее масштабирование (hot-resize) позволяет добавлять CPU, RAM или диск без перезагрузки.

Автоматизация

Шаблоны для быстрого развёртывания: Django, Redmine, Tomcat, Teamspeak, Nextcloud, LAMP, LEMP, Forgejo Git, GitLab, Битрикс. Поддерживаются ОС Linux (Ubuntu, Alma, Debian, Rocky, CentOS, Oracle), FreeBSD, Windows Server. API и панель ispmanager 6 lite (бесплатно на месяц) упрощают управление.

Безопасность

Включена защита от DDoS-атак на сетевом уровне, BitNinja для защиты сервера и сайта, SSL-сертификаты GlobalSign. Доступны автобэкапы, снапшоты, Кибер-бэкап и объектное хранилище S3 для больших данных.

Поддержка

Круглосуточная поддержка 24/7 без чат-ботов, ответ до 15 минут через чат, личный кабинет или телефон. Бесплатно: помощь с активацией и первичной настройкой. Платно: установка ПО, администрирование. Экспертная линия для мониторинга и устранения сбоев.

Бонусы

• Тестовый период 3 дня.
• Бесплатный перенос до 10 сайтов с другого хостера.
• Скидки: 40% на первый месяц при оплате на 1/3/6 месяцев или 3 месяца бесплатно при оплате за год.
• Лояльность: скидка 5–20% для клиентов от 5 лет.
• Реферальная программа: 10% от расходов привлечённых клиентов для партнёра, 25% скидка для нового пользователя на первый месяц.
• Домены: продление по цене регистрации.

Тарифы и условия

Тестовый период 3 дня, после него подключаете один из основных тарифов:

• Линейка готовых конфигураций от 1 CPU, 1 Гб RAM, 40 Гб SSD-накопителя и от 219 руб/мес. до сервера с 8 CPU, 12 Гб RAM, 150 Гб NVMe-накопителя. Локация в РФ и Нидерландах.
• VDS Форсаж: на AMD Epyc от 749 ₽/мес. Локации: РФ и Нидерланды.
• CPU.Турбо: гибкая конфигурация на базе высокочастотных AMD Ryzen 9 от 624 ₽/мес. При покупке лицензии Битрикс дополнительная скидка 30% на 3 месяца аренды CPU.Турбо. Локация в РФ.
• VDS Атлант: отказоустойчивый с автобэкапами от 1 619 ₽/мес. Локация: РФ.
• VDS Storage: сервис как хранилище с гибкой конфигурацией от 704 ₽/мес. Локация: РФ

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

2. UltraVDS: для малого бизнеса и стартапов

Компания UltraVDS, провайдер услуг виртуальных серверов (VPS/VDS), работает на рынке с 2014 года — предлагает решения для разных операционных потребностей. Сервисы UltraVDS можно использовать для развертывания торговых роботов, запуска чат-ботов, хостинга веб-сайтов, а также для создания FTP-хранилищ данных. Есть предложения для фрилансеров, цифровых агентств, корпоративных пользователей и стартапов, которым требуются функциональные инфраструктурные решения.

Технические особенности

Серверы UltraVDS размещены в современном дата-центре, расположенном в Москве. Доступность сервиса (аптайм) составляет 99,98%, что обеспечивает высокую стабильность работы. Сетевая пропускная способность превышает 200 Мбит/с, при этом трафик предоставляется без ограничений.

Система защиты от DDoS-атак способна обрабатывать трафик до 1,5 Тбит/с и поддерживает стабильность работы сервера даже при интенсивном внешнем воздействии. Лицензия на Windows Server входит в стоимость обслуживания в данном предложении. Это упрощает развертывание сервера: вам не нужно отдельно покупать и устанавливать лицензию. Плюс снижает общие операционные расходы для пользователей этой операционной системы.

Тарифные планы

Для новых пользователей UltraVDS предусмотрена возможность 3-дневного тестового периода, позволяющего оценить функциональность и производительность сервиса.

После тестового периода стоимость тарифов начинается от 119 рублей в месяц. На сайте доступен онлайн-калькулятор, позволяющий подобрать конфигурацию сервера и рассчитать итоговую стоимость.

Клиентам доступны различные варианты оплаты, включая ежемесячную систему без предоплаты. При авансовой оплате на период от 3 до 12 месяцев предоставляются скидки до 20%, размер которых зависит от выбранного срока. В случае досрочного прекращения использования сервиса, неиспользованный остаток средств возвращается на баланс пользователя.

Поддержка и обслуживание

Техническая поддержка UltraVDS работает круглосуточно, 7 дней в неделю. Среднее время ответа на запросы составляет до 15 минут. Связь со службой поддержки возможна по электронной почте и телефону, указанным на официальном сайте.

3. RUVDS: 10 лет на рынке облачных решений

RUVDS — облачный провайдер, имеющий десятилетний опыт работы на рынке услуг виртуальных серверов (VPS/VDS). Является официальным партнером Huawei в России, работает по SLA. Компания предоставляет инфраструктурные решения, которые могут быть применены для широкого спектра задач, включая хостинг высоконагруженных интернет-магазинов, корпоративных порталов, игровых серверов, сложных backend-систем и чат-ботов.

Платформа RUVDS спроектирована для оптимизации процесса развертывания ресурсов. Одной из ее особенностей является маркетплейс, который позволяет быстро запускать серверы с предустановленным программным обеспечением. Это способствует ускорению старта проектов, снижая потребность в ручной настройке распространенных CMS, игровых серверов и сред разработки.

Тарифная политика и варианты оплаты

RUVDS предлагает различные тарифные планы. Например, стоимость конфигурации Linux-сервера (1 CPU, 512 МБ RAM, 10 ГБ HDD, 1 IPv4) начинается от 139 ₽/месяц. Это может быть рассмотрено как экономичное решение для запуска небольших проектов и проведения тестирования.

Клиентам доступны разные опции оплаты:

1. Ежемесячные платежи или предоплата на срок от 3 до 12 месяцев, при которой предоставляются скидки до 20%, зависящие от продолжительности периода.
2. Для проектов с динамической нагрузкой предусмотрена посекундная тарификация, оплата по которой взимается только за фактически использованные ресурсы. Неиспользованный остаток средств в рамках этой модели возвращается на баланс пользователя

Дополнительно, до конца 2025 года панель управления ISP Manager для сервера и сайта предоставляется без дополнительной платы при создании любого VPS.

Глобальная инфраструктура и стабильность

Инфраструктура включает 17 дата-центров уровня Tier III, расположенных по всему миру. Это один из самых больших показателей по количеству геолокаций среди российских провайдеров. Для работы используются корпоративное оборудование и накопители (HDD, SSD, NVMe), чтобы обеспечить стабильную работу и производительность размещенных проектов.

Поддержка клиентов и доступные ресурсы

Техническая поддержка RUVDS доступна круглосуточно, 7 дней в неделю. Среднее время ответа на запросы через тикет-систему или онлайн-чат составляет 15 минут. Клиентам предоставляются полные административные права и консультации по вопросам запуска и настройки серверов. Для самостоятельного изучения доступна база знаний, включающая инструкции и руководства.

Безопасность и масштабирования

В контексте безопасности данных, RUVDS предлагает несколько решений:

- Встроенная защита от DDoS-атак, способствующая поддержанию бесперебойной работы серверов при внешнем воздействии.

- Стандартный IPv4-адрес включен в стоимость каждой виртуальной машины, с опцией аренды дополнительных IP-адресов.

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

- Компания официально подтверждает соответствие требованиям ФСТЭК и ФЗ-152 по защите персональных данных, что обеспечивает соблюдение соответствующих законодательных норм.

4. McHost: решения для бизнеса разного масштаба

McHost предоставляет комплексные хостинговые решения, включая виртуальный хостинг и VPS/VDS с NVMe-накопителями. Сервис поддерживает популярные CMS (WordPress, Joomla, 1С-Битрикс) с оптимизированными настройками и автоматической установкой через панель управления.

McHost ориентирован на широкий круг клиентов:

• владельцы сайтов-визиток, блогов и лендингов — благодаря низким тарифам и полному набору опций;
• интернет-магазины с небольшой нагрузкой — тарифы с SSD-накопителями и автоматическим резервным копированием обеспечивают стабильную работу;
• разработчики, которым нужны
  VPS/VDS с root-доступом — работают серверы на KVM-виртуализации с ОС Linux и Windows;
• госучреждения и компании,
  работающие с персональными данными — соответствие 152-ФЗ и размещение в дата-центрах Tier III в Москве.

Особенности сервиса

McHost поддерживает стабильную работу с аптаймом 99.9% за счет размещения оборудования в дата-центрах уровня Tier III — в Москве и Нидерландах.

Сервис предоставляет защиту от DDoS-атак, автоматическое резервное копирование раз в два дня с хранением данных в течение 30 дней для виртуального хостинга и 14 дней для VPS, а также поддержку российских криптографических стандартов. Клиентам доступны различные варианты размещения: от виртуального хостинга с SSD (от 157.5 ₽/мес) до выделенных серверов с NVMe-накопителями.

Технические параметры и условия

Инфраструктура McHost базируется на серверах Dell с NVMe-накопителями и процессорами Intel Xeon (частота ядер от 2.35 ГГц). Для виртуального хостинга используется CloudLinux с технологией CageFS, обеспечивающей изоляцию аккаунтов. Поддержка российских ОС («Альт») подтверждена для VPS-тарифов.

В техподдержку можно обратиться по телефону, через тикет или в Telegram-боте. Время ответа — до 10 минут.

Текущие тарифы:

• Виртуальный хостинг: от 157 ₽/мес
  (3 ГБ SSD, 1 сайт).
• VPS: от 396 ₽/мес (15 ГБ SSD, 1
  ядро CPU).
• Выделенные серверы: от 3 000 ₽/мес
  (32 ГБ RAM, 2×1 ТБ HDD).

5. UFO Hosting: VPS/VDS и выделенные серверы с портом до 10 Гбит/с и безлимитным трафиком

UFO Hosting предлагает VPS/VDS и выделенные серверы на партнёрской инфраструктуре IXcellerate (Tier III). В портфолио — недорогие виртуальные машины и серверы с портом 10 Gbps для проектов, которым нужна стабильность без завышенных цен.

Сервис подходит для пользователей разных масштабов: от фрилансеров и веб‑студий до средних и крупных компаний. Для DevOps‑специалистов доступны API и инструменты автоматизации.

Основные сценарии использования

• корпоративные сайты, CRM‑системы и веб‑приложения;
• аналитические сервисы и SaaS‑продукты;
• инфраструктура для разработки и тестирования;
• задачи фрилансеров, агентств и digital‑команд.

Формат работы, особенности и интеграции

Серверы установлены в российском дата‑центре Tier III (IXcellerate), что означает резервирование по питанию и каналам связи. Заявленный аптайм — 99,98 %. Поддержка работает круглосуточно в тикетах, чате и по телефону; среднее время ответа 5–10 минут.

Сервис UFO Hosting делает акцент на безопасности и гибкости. Есть сеть с защитой от DDoS, возможность горячего расширения ресурсов, автоматическое развёртывание из шаблонов и API для интеграции. Поддерживаются популярные фреймворки и CMS, есть интеграции с GitLab, Telegram и DockerHub. Бэкапы, снапшоты и резервирование входят в стандартный набор, так что восстанавливать тестовую среду не придётся вручную.

В панели управления можно автоматически установить популярные CMS, панели управления, хранилища и DevOps‑инструменты. Это экономит время на настройку и подходит тем, кто не хочет поднимать всё с нуля.

Условия использования и тарифы

Базовые конфигурации начинаются от 577 руб./месяц. Заявленная скорость порта — до 10 Gbps, что подходит для проектов, где много трафика.

Есть возможность бесплатно попробовать сервис присутствует, но предоставляется по запросу в поддержку, а при оплате на срок от трёх месяцев действуют скидки, а также регулярно проводятся акции: это поможет оптимизировать бюджет.

В целом, UFO Hosting выглядит как практичное решение для тех, кому нужны производительные VPS/VDS и выделенные серверы в России. При выборе стоит оценить, насколько конфигурации подходят под конкретные нагрузки и есть ли необходимость в интеграциях из коробки.

6. Timeweb: хостинг для веб-проектов

Timeweb предоставляет услуги хостинга для различных типов веб-проектов. Сервис поддерживает популярные CMS, включая WordPress, 1C-Битрикс и Joomla, что делает его подходящим как для личных блогов, так и для корпоративных сайтов.

Платформа использует собственную панель управления с инструментами для работы с сайтами, базами данных и резервными копиями. Ежедневное автоматическое резервное копирование с хранением данных до 30 дней включено во все тарифные планы. Базовая защита от DDoS-атак доступна для всех клиентов без дополнительной платы.

Инфраструктура Timeweb размещена в дата-центрах уровня Tier III в России (Санкт-Петербург) и Казахстане (Алматы). Гарантированный показатель uptime составляет 99.98%. Поддерживаются современные технологии: PHP версий от 5.3 до 8.4, MySQL от 5.6 до 8.0, а также Perl, Python, SSH, FTP и Cron.

Тарифные планы:

• Year+: от 164 ₽/мес (2 сайта, 15
  ГБ NVMe, 2 БД);
• Optimo+: от 248 ₽/мес (15 сайтов,
  40 ГБ NVMe, безлимитные БД);
• Century+: от 347 ₽/мес (35 сайтов,
  50 ГБ NVMe, безлимитные БД);
• Millennium+: от 482 ₽/мес (60
  сайтов, 60 ГБ NVMe, безлимитные БД).

Все тарифы включают бесплатный SSL-сертификат, 10 ГБ почтовой квоты с неограниченным количеством ящиков и DNS-хостинг. При оплате годового тарифа предоставляется домен в зонах .RU/.РФ в подарок.

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

7. Reg.ru: комплексные решения для сайтов и доменов

Reg.ru сочетает услуги хостинга и регистрации доменов, что упрощает управление веб-проектами. Компания работает с 2005 года, имеет статус аккредитованного регистратора доменных имён в зонах .RU и .РФ.

Функциональные возможности

Платформа предоставляет доступ к трём панелям управления: ISPmanager, cPanel и Plesk. Это позволяет выбрать наиболее удобный интерфейс для работы с сайтами. Все тарифы включают бесплатный SSL-сертификат от Let’s Encrypt, который автоматически устанавливается при создании сайта.

Начинающим пользователям доступен конструктор сайтов с готовыми шаблонами. Поддерживаются популярные CMS, включая WordPress, Joomla и 1С-Битрикс. Ежедневное резервное копирование данных с хранением копий в течение 30 дней входит в стандартный набор услуг.

Техническая инфраструктура

Серверы размещены в дата-центрах уровня Tier III в Москве. Средний показатель uptime составляет 99.9%, что подтверждается ежемесячной статистикой. Подключение к сети осуществляется по выделенным каналам со скоростью до 1 Гбит/с на выделенных серверах.

Поддержка и тарифы

Техническая поддержка доступна 24/7 через онлайн-чат и тикет-систему. Среднее время ответа составляет 15-20 минут. Для срочных вопросов можно обратиться по телефону.

Тарифы — от 151 ₽/мес (7 ГБ SSD, 15 сайтов). При регистрации домена в зонах .RU или .РФ предоставляется скидка на другие доменные имена.

8. Спринтхост: хостинг с персональным подходом

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

Особенности сервиса

Компания предоставляет персонального менеджера для каждого клиента, который помогает с настройкой сервера и решением технических вопросов. А если вы остались недовольны услугами, то в течение 30 дней сервис вернёт деньги. Sprinthost проводит бесплатные обучающие вебинары по DevOps и администрированию серверов.

Технические характеристики и тарифы

Инфраструктура размещена в дата-центрах Москвы и Санкт-Петербурга с аптаймом 99.9%. Поддерживаются современные технологии разработки, включая Ruby on Rails, Node.js, Python и Docker. Все серверы используют SSD-накопители с гарантированной скоростью чтения/записи.

Тарифные планы:

• Start: 290 ₽/мес (1 ядро, 1 ГБ
  RAM, 15 ГБ SSD);
• Turbo: 1 900 ₽/мес (4 ядра, 8 ГБ
  RAM, 100 ГБ NVMe).

Поддержка

Техническая помощь доступна 24/7 через тикет-систему и онлайн-чат. Среднее время ответа составляет 10-15 минут. Для корпоративных клиентов предусмотрена приоритетная поддержка по телефону.

Как выбрать хостинг в 2025 году

Выбор хостинга зависит от типа проекта и его требований. Для небольших сайтов и блогов подойдет виртуальный хостинг с поддержкой популярных CMS — важно проверить наличие автоматических бэкапов и базовой защиты от DDoS. Если проект связан с обработкой персональных данных, убедитесь, что провайдер соответствует 152-ФЗ и использует сертифицированное оборудование.

Для высоконагруженных сервисов и интернет-магазинов лучше рассматривать VPS или выделенные серверы. Обратите внимание на тип накопителей (SSD/NVMe), возможность масштабирования ресурсов и аптайм дата-центров (рекомендуется от 99.9%).

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

Главное правило — выбирайте решение, которое покрывает текущие потребности проекта. Важно, чтобы конфигурацию можно было оперативно менять по мере роста запросов и масштабирования бизнеса. Технологии меняются быстро, и гибкость конфигурации часто важнее сиюминутной экономии.

FAQ

Что такое виртуальный хостинг и когда его выбирать?

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

Преимущества: низкая стоимость, простота управления через панели, автоматические обновления и базовая защита. Минусы: ограниченные ресурсы; производительность зависит от соседних сайтов; минимальный контроль над настройками.

Что такое VPS/VDS и для каких проектов он подходит?

VPS (Virtual Private Server) или VDS — это виртуальный сервер с выделенными ресурсами (процессор, память, диск), предоставляющий доступ для полной настройки. Идеален для проектов среднего масштаба: интернет-магазинов, API, SaaS, чат-ботов, корпоративных порталов или приложений с умеренным трафиком.

Преимущества: гибкость конфигураций, выбор ОС, изоляция ресурсов. Минусы: требует базовых навыков администрирования, стоимость выше, чем у виртуального хостинга.

Что такое выделенный сервер и когда его использовать?

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

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

В чём основные различия между виртуальным хостингом, VPS и выделенным сервером?

Виртуальный хостинг — самый дешёвый и простой, но ресурсы делятся между пользователями, что ограничивает производительность (до 1000–2000 посетителей в сутки).

VPS обеспечивает выделенные ресурсы и гибкость, справляясь с нагрузкой до 5000–10 000 пользователей в сутки.

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

Выбор зависит от масштаба: виртуальный для старта, VPS для роста, выделенный для enterprise.

Нужны ли навыки администрирования для хостинга?

Для виртуального хостинга навыки не нужны — управление идёт через интуитивные панели, а провайдеры обеспечивают обновления и базовую поддержку. Для VPS желательны базовые знания (настройка ОС, установка ПО), хотя многие провайдеры предлагают помощь. Для выделенного сервера навыки администрирования необходимы, так как вы полностью отвечаете за сервер, хотя провайдеры могут предлагать платное администрирование.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

Когда мы говорим об углеродном следе ПО, важно понимать: код не существует в вакууме. Каждая строка, каждый запрос и каждая операция требуют физических ресурсов — электричества, серверного оборудования, систем охлаждения. В 2025 году эта цепочка стала еще сложнее из-за взрывного роста облачных вычислений и ИИ.

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

Климатические инициативы в IT больше не просто красивые слова в корпоративных отчетах. В 2025 году за неэффективный код можно получить не только порицание сообщества, но и вполне реальный штраф.

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

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

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

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

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

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

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

Больше новостей — в нашем тг-канале Представляешь

Как это работает

Внутри платформы есть готовые API: Unlocker API помогает обходить CAPTCHA и блокировки, Browser API собирает динамический контент, SERP API получает структурированные данные из поисковиков, а Crawl API позволяет выгружать данные с целых доменов по одной команде. Для ИИ-команд это значит, что можно не тратить время на настройку обхода защит, а сразу получать нужные данные в чистом виде.

Разработчики могут строить пайплайны для ML/AI, аналитики, мониторинга рынка и конкурентов, обновления поисковых индексов или исследования трендов. Данные предоставляются как в режиме hands-off (Bright Data отдаёт их в готовом виде), так и через API и пайплайны, если команда хочет полный контроль.

Что есть для разработчиков

Платформа совместима с любыми пайплайнами ML и BI, работает с Python, Node.js и другими стеком, поддерживает интеграцию в существующую инфраструктуру через API. Поддержка масштабируемости позволяет выгружать данные в реальном времени или подгружать исторические архивы для обучения LLM.

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

Для чего это использовать

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

Bright Data предлагает бонус новым пользователям: первый депозит удваивается до $500, чтобы можно было протестировать платформу без риска. Платформа доступна по подписке и в виде оплаты по использованию, позволяя адаптировать расходы под объём задач.

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

Один API не может эффективно обслуживать разные типы клиентов. Сайт, приложение для iOS, Android, умные часы — у каждого свои потребности в данных, ограничения по производительности и особенности интерфейса.

Монолитный API создают с расчётом на универсальность — на практике это приводит к компромиссам. Веб-версии нужны данные для сортировки, мобильному приложению — минимальный набор для экономии трафика.

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

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

Обычно данные приходят в неудобном виде: несколько связанных сущностей нужно запрашивать отдельно и склеивать на клиенте. BFF берёт эту работу на себя.

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

Каждый клиент получает данные в том виде, в котором может их сразу отобразить. Вместо загрузки 50 полей, из которых используется 5, BFF отдаёт только нужные данные.

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

BFF размещается между клиентскими приложениями и основными бэкенд-сервисами, выполняя роль посредника. В отличие от API Gateway, который просто перенаправляет запросы, BFF трансформирует данные.

Архитектура взаимодействия

Классическая схема выглядит так: мобильное приложение обращается к своему BFF, веб-приложение — к своему, умные часы — к третьему. Каждый BFF знает особенности своего клиента и общается с основными сервисами на их «языке».

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

• берёт базовую информацию о заказах,
• подтягивает данные о товарах,
• получает статусы доставки.

Затем склеивает всё в один ответ, отбрасывая ненужные поля и добавляя вычисляемые значения.

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

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

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

Независимость и масштабирование

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

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

Количество запросов тоже сокращается. Например, чтобы показать профиль пользователя, фронтенд делает 5 запросов:

• за основными данными,
• аватаром,
• списком друзей,
• последними постами,
• настройками приватности.

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

• парсинг дат,
• группировку массивов,
• вычисление производных значений.

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

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

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

Появляется возможность экспериментировать с технологиями без риска. Хотите попробовать GraphQL для веб-версии? Внедряйте в один BFF. Тестируете новую базу данных? Подключайте к экспериментальной прослойке, не трогая продакшн.

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

Красный флаг — когда фронтенд-разработчики начинают писать костыли для обработки «неудобных» данных. Если половина JavaScript-кода занимается парсингом и трансформацией ответов API, что-то пошло не так.

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

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

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

Когда команды работают независимо

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

Если у вас простое приложение с одним клиентом, BFF добавит лишнюю сложность. Если API уже идеально подходит всем клиентам, зачем что-то менять?

3 типичные ошибки при внедрении BFF

Дублирование логики

Начинается незаметно: мобильный и веб BFF нуждаются в одинаковой валидации пользователей. Разработчик копирует функцию из одного проекта в другой. Через полгода одинаковый код валидации живёт в четырёх местах, и каждое изменение превращается в квест.

Хуже, когда дублируется бизнес-логика. Расчёт скидок, обработка промокодов, правила доступа — это должно жить в основных сервисах, а не размазываться по BFF-слоям.

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

Другая крайность — микро-BFF для каждой мелочи. Отдельный слой для авторизации, отдельный для форматирования дат, отдельный для валидации.

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

Частая ошибка — создание BFF по организационному принципу, а не по техническому. У нас три фронтенд-команды, значит нужно три прослойки. Но если все команды работают с похожими данными и интерфейсами, логичнее объединить усилия.

Практические примеры использования BFF

Netflix

Компания сделала разные API для веб-версии, мобильных приложений, Smart TV и игровых консолей. Каждый BFF оптимизирован под особенности устройства, например, TV-версия предзагружает больше контента из-за медленной навигации пультом.

Spotify

Используют BFF для разных клиентов: веб-плеер, мобильные приложения, десктопное приложение. Мобильный BFF агрессивно кеширует данные для офлайн-режима, веб-версия работает в реальном времени.

SoundCloud

Публично описывали переход на BFF-архитектуру. У них отдельные слои для веб-версии и мобильных приложений, которые по-разному обрабатывают аудиопотоки и метаданные треков.

Заключение

Страдают все, когда один API пытается обслуживать веб-версию, мобилки и что-то ещё. Фронтенд получает неудобные данные, бэкенд обрастает костылями, пользователи — медленными приложениями.

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

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

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

В статье рассмотрим:

- Установку локально и в облаке;

- Интеграцию с Python, Node.js и PHP;

- Примеры автоматизаций;

- Интеграцию с AI Mistral.

Установка n8n

Локальная установка

Нам потребуется Docker, проверьте установку:

Шаги установки:

1. Создайте том данных:

2. Запустите контейнер:

После запуска откройте: `http://localhost:5678`

Установка на удаленном сервере

Развертывание мы произведем в облаке Amvera, так как в нем n8n предоставляется как преднастроенный сервис с бесплатным доменом (он нам нужен), настроенными переменными и проксированием до заблокированных в РФ LLM (OpenAI, Gemini, Claude и др.).

1. Регистрируемся на Amvera;

2. Выбираем n8n в плитке на главной странице;

3. Вводим название для проекта и выбираем тариф.

Готово, через 30 секунд запустится n8n с выделенным доменом и настроенными основными переменными.

Настройка n8n

Первоначальная настройка

1. Откройте n8n (локально: `localhost:5678`, в облаке: ваш домен)

2. Заполните данные администратора:

• Email

• Имя/Фамилия

• Пароль

3. По желанию вы можете получить бесплатный лицензионный ключ:

• Введите email → "Send me a free license key"

• Активируйте в разделе Settings → Usage

Настройка для HTTP

1. Создайте новый workflow → Start from scratc

2. Добавьте триггер: Webhook - On webhook call

3. Настройте:

• HTTP Method: POST

• Path: `/n8n` (пример)

• Respond Mode: Using 'Respond to Webhook' node

4. Добавьте обработчик: Core → Respond to Webhook

5. Настройте ответ:

Примеры использования

Пример на Python

В примере на Python мы сделаем калькулятор. Суть: отправляем выражение через POST, n8n делает вычисление, возвращаем результат.

Workflow:

1. Добавьте Core → Code node между Webhook и Respons:

Клиент (Python):

Запустим код и посмотрим результат:

Пример на PHP

В примере на PHP мы сделаем валидацию данных. Суть: отправляем данные через POST, n8n проверяет данные, возвращает результат.

Workflow (Code node):

Клиент (PHP):

Можем зайти на нашу страницу, все работает нормально:

Пример на Node.js

Примером на node.js будет фильтр запрещенных слов. Суть: отправляем текст, n8n проверяет на наличие плохих слов, возвращает результат.

Workflow (Code node):

Клиент (Node.js):

Перед запуском установим библиотеку командой `npm install axios`

Интеграция n8n с Mistral AI

Мы интегрируем нейросеть Mistral в телеграмм-бота на C# с помощью n8n. Перед тем как начать, нам нужно получить токен.

1. Зарегистрируйтесь на Mistral

2. Создайте агента Сreate an agent

3. Перейдите в раздел API Keys

4. Создайте и скопируйте API-ключ (звездочки наложены):

Теперь нужно создать credentials для работы с созданной моделью. Для этого в правом верхнем углу нажмите Create credentials. В списке найдите Mistral Cloud API. В открывшемся окне вставьте скопированный ключ и сохраните.

Осталось настроить workflow.

1. Добавляем Webhook:

• Method: POST

• PATH: n8n

• Respond: Using 'Respond to Webhook' Node

2. Добавляем AI Agent:

• Source for Prompt: Define below

• Prompt: `{{ $json.body.text }}`

3. Подключаем Chat Model к созданному агенту:

• Credential to connect with: Mistral Cloud API

• Model: mistral-large-2411

4. Добавляем Respond to Webhook

Вот так выглядит готовый workflow:

Можем приступить к созданию бота. Для начала введите эти команды по очередности:

Переходим в папку с кодом и редактируем файл `Program.cs`:

Запустите бота с помощью команды `dotnet run`.

Автоматизируем с помощью n8n

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

Для работы с Telegram Node понадобиться создать credentials Telegram API. Туда вставляем токен бота, полученный в @BotFater. Сохраняем и переходим к настройке workflow.

Создаем новый workflow.

1. Добавляем On form submission. В качестве примера я создам самую простую форму:

Перейдите по ссылке в Producrion URL чтобы заполнить форму.

2. Добавляем Telegram Node:

• Credential to connect with: Telegram account

• Resource: Message

• Operation: Send message

• Chat ID: вставьте свой telegram id

Text:

Готово! При новых заявках бот будет присылать уведомления.

Деплой бота в Amvera Cloud

Перед тем как начать деплой, мы должны создать конфигуационнный файл `amvera.yml`. Для этого создаем его в рабочем каталоге с ботом и вводим следующее:

Строго говоря, этот файл проще создать в конфигураторе в интерфейсе.

2. Структура проекта будет такой:

tg-bot/

├── Program.cs

├── tg-bot.csproj

├── amvera.yml

├── bin/

└── obj/

Идем В Amvera Cloud и создаем приложение Приложения — Создать приложение. Вводим название и выбираем тариф.

Далее загружаем все файлы, что есть у нас в каталоге, с ботом. В конце будет окно с настройкой конфигуцрации, выглядит оно так:

Нажимаем Завершить и ждем когда приложение будет запущено.

Заключение

n8n — мощный инструмент для создания интеграций и автоматизаций. Надеюсь, статья была вам полезна и буду рад обсудить в комментариях любые вопросы!

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

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

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

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

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

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

*Инструкция для Windows. Надеюсь, проблем при установке ни у кого не возникнет.

Основные шаги по установке

Установка VS Code

1. Перейдите на оф. сайт https://code.visualstudio.com/ и скачайте последнюю версию. На главной странице должна отображаться кнопка Download for Windows.
2. Дальше стандартная установка по инструкции: Next > Next > Install.

Установка Node.js. Шаги аналогичные

1. Также перейдите на оф. сайт https://nodejs.org/en/download и скачайте последнюю версию Node.js. Я использовал Windows Installer (.msi).
2. Такая же стандартная установка: Next > Next > Install.

Создание проекта

1. Создайте пустую папку на ПК, где будет храниться проект для автоматизации.
   У меня для этого есть отдельная директория, так удобнее хранить все проекты в одном месте. Но её можно создать даже на рабочем столе, разницы никакой. Мой путь к папке — C:\Users\Pavel\Projects\TestProject.
2. Запустите VS Code и там выберите созданную папку.

Установка Playwright

1. Перейдите в раздел управления расширениями Extensions.
2. Введите Playwright в поисковой строке.
3. Нужно скачать тот, что верифицирован Microsoft (у него больше всего установок).

Но установка еще не закончена, дальше:

• Вызовите Command Palette. Можно через основное меню: View > Command Palette или комбинацией клавиш Ctrl+Shift+P.
• Введите Test: Install Playwright в появившейся строке.
• Выберите необходимые браузеры для установки.
• Я оставляю только Chromium, его вполне достаточно. Кликаем Ok и ждем окончательной установки Playwright (должен появиться терминал и начаться установка пакетов).

Создание тестов

1. В основном окне Explorer добавьте новый файл в модуле tests (правая кнопка мыши, новый файл).
   *Важно, чтобы название файла оканчивалось на spec.ts или .test.ts (расширение может быть и .js): так Playwright определяет тесты по дефолту. В примере добавил файл login.spec.ts.

1. Вставьте следующий код в созданный файл login.spec.ts.
   Это пример логина на платформе, который ± подходит под любой сайт: нужно только изменить URL, locators и данные для входа. Использую тестовую платформу https://demowebshop.tricentis.com/.

Осталось совсем немного. Только запустить созданный тест:

1. Перейдите в раздел Testing.
2. Выберите созданный файл и запустите тесты кликом Run test.

Можете добавить еще один тест в тот же файл и посмотреть его выполнение:

Вот и всё! Теперь у вас есть базовая автоматизация с Playwright! Дальше можно дописывать другие тесты. Например, посмотреть работу системы с незарегистрированным email, вынести credentials в конфигурационный файл и т.д. И, конечно, углубляться, разбираться во всем, чтобы стать уверенным автоматизатором. Можно продолжить изучение статей на оф.сайте Playwright. Главное, соблюдайте best-practices при работе с ним.

Откуда началось: мой путь в финтех

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

Finance.kz существовал уже более 3 лет, но работал как классический сайт-витрина. Когда я пришёл в проект год назад, стало ясно: нужно полностью переосмыслить подход и создать технологическое решение нового поколения.

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

Эти компании привозят готовые решения, которые хорошо работали в России или других рынках. На первый взгляд их продукты выглядят более зрелыми — красивые интерфейсы, отработанные воронки конверсии. Но у импортных решений есть критический недостаток: они плохо адаптированы под специфику казахстанского рынка.

Технологические вызовы: интеграция с госсервисами и банками

Главная боль при разработке агрегатора в Казахстане — это интеграции. В отличие от рынков СНГ, здесь нельзя обойтись простым партнёрским трафиком. Пользователи хотят получить продукт онлайн, полностью, без походов в офисы.

API-интеграции с банками и МФО

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

Техническая сложность — в разнородности API. Каждый банк использует собственные протоколы, форматы данных и методы аутентификации. Пришлось создать унифицированный слой-адаптер, который «переводит» наши запросы в формат, понятный конкретной финансовой организации.

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

Работа с госAPI — отдельная история. Протоколы меняются, документация часто устаревает, а техподдержка работает в режиме «как получится». Но результат того стоит: время оформления кредита сокращается с нескольких дней до 15-30 минут.

Архитектура продукта: ставка на микросервисы

При проектировании архитектуры Finance.kz мы отказались от монолитного подхода в пользу микросервисов. Это решение диктовалось спецификой агрегатора — нам нужно было обеспечить высокую доступность при интеграции с десятками внешних систем.

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

Наша главная идея — превратить агрегатор из витрины в полноценный финтех-сервис. Пользователь должен получить продукт полностью онлайн: от сравнения условий до перечисления денег на карту.

Для этого мы реализовали несколько ключевых функций:

• Умный подбор продуктов на основе данных пользователя и машинного обучения
• Предварительный скоринг для оценки вероятности одобрения ещё до подачи заявки
• Автоматическое заполнение анкет с подтягиванием данных из госсервисов
• Отслеживание статуса заявки в реальном времени

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

Конкурентные преимущества: локализация против красивых интерфейсов

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

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

Ближайшие 1-2 года будут критичными для всего рынка. Мы видим несколько ключевых направлений развития:

Расширение продуктовой линейки

Планируем добавить страхование, депозиты и инвестиционные продукты. Цель — стать единой точкой входа для всех финансовых потребностей пользователя.

Внедрение ИИ и машинного обучения

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

Международная экспансия

Рассматриваем возможность выхода на рынки Узбекистана и Кыргызстана. Наша технологическая платформа легко масштабируется на соседние рынки.

Собственные финансовые продукты

В долгосрочной перспективе планируем получить лицензию МФО и предлагать собственные займы наиболее качественным клиентам.

Уроки и выводы

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

Второй важный момент — команда решает всё. Мы собрали людей, которые понимают как технологии, так и специфику финансового рынка. Это даёт нам фору перед конкурентами, которые пытаются адаптировать готовые решения силами удалённых команд.

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

Почему «тормоза» — это не всегда про код

Когда пользователь жалуется на «медленное приложение», большинство разработчиков по привычке лезет в код. Профилируем, ищем неэффективные циклы, оптимизируем до запятых. Но в реальности причина часто не в логике, а в том, что её окружает.

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

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

Многие из них — не баги, а последствия архитектурных решений. В дев-среде всё летает, потому что:

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

Когда приложение тормозит, мы часто копаемся в отдельных компонентах — фронте, бэке, базе. Но bottleneck может быть не внутри компонента, а между ними: в конфигурации, связях, сетевых задержках, очередях вызовов.

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

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

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

• Кэш не промахивается, но и не помогает — stale данные, повторные чтения, инвалидация не работают, как ожидалось.

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

Оптимизация кода важна. Но если система тормозит, искать нужно по всей цепочке — от кнопки на фронте до брокера в соседнем дата-центре.

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

Архитектура доступа к данным: как закладываются тормоза

Архитектура доступа к данным — фундамент, на котором держится производительность всей системы. Даже идеальный алгоритм или быстрый backend не спасут, если данные извлекаются медленно, неэффективно или избыточно.

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

• Очередь перегружена, и событие просто стоит в хвосте.
• Обработчик падает или рестартится, и событие ждёт.
• Политики повторной обработки не настроены — событие крутится бесконечно.
• Слишком много этапов внутри одного воркера: валидация, запись в БД, вызов API — всё это задержки, которые суммируются.

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

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

Для защиты от переполнения очереди нужно мониторить несколько важных показателей:

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

Если тормозит хотя бы один, сыплется всё. Получается эффект домино и каскадные отказы, где неполадка в одном звене рвёт всю цепочку.

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

Иногда архитекторы увлекаются и дробят сервисы до абсурда. Начинается с «давайте переиспользуем», а заканчивается 10 API-вызовами ради одного действия.

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

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

Вот несколько типичных ошибок, которые приводят к деградации производительности:

Невалидные или слишком агрессивные стратегии

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

А если кэш сбрасывается при каждом изменении, он вообще не успевает выполнять свою роль. В итоге: нестабильное поведение, непредсказуемая производительность и раздражённые пользователи.

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

• работают на одной машине без шардинга;
• содержат тяжёлые объекты;
• используются как универсальный ответ на все проблемы.

В таких случаях кэш из «ускорителя» может падать под нагрузкой быстрее, чем база данных.

Кэш-миссы и лавины запросов

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

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

Если в системе несколько уровней кэширования (CDN, фронтовый кэш, Redis) и они обновляются по-разному, возникает несогласованность. Один пользователь видит новые данные, другой — старые. Один сервис работает с актуальной версией, другой — с устаревшей. Начинается охота за фантомами: баги вроде есть, но не у всех.

Вычисления и память: что не так с аллокацией

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

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

• очередь задач не может масштабироваться под нагрузку.

В таких случаях нагрузка растёт, а пропускная способность — нет. Всё упирается в искусственное ограничение, введённое «на всякий случай».

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

• Когда проявляется проблема: под нагрузкой, в пиковые часы, у конкретных пользователей?
• Что именно работает медленно: API, отчёты, фоновая обработка?
• Как это влияет на систему: задержки, таймауты, ошибки?

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

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

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

После подтверждения проблемы можно переходить к исправлениям:

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

После изменений обязательно перепроверьте метрики, чтобы убедиться, что оптимизация действительно дала эффект — и не добавила новых узких мест.

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

Главная проблема в том, что узкие места проявляются не сразу, а под нагрузкой. В разработке и тестах всё летает, потому что ресурсов хватает. А вот в проде — особенно при росте аудитории — на поверхность всплывает всё, что не выдерживает реального объёма данных или конкуренции за ресурсы.

Чтобы избежать таких проблем, важно не просто писать чистый код, а мыслить системно: проектировать архитектуру так, чтобы она могла жить под давлением. Вот несколько принципов, которые помогут.

Думайте об объёмах и росте

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

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

Любая система может начать тормозить — вопрос в том, как она себя при этом поведёт. Важно предусмотреть мягкую деградацию: таймауты, очереди, резервные сценарии, ограничение входящего трафика.

Не усложняйте архитектуру без повода

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

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

Откуда возник CORS

Всё началось в начале 2000-х, когда веб-приложения становились всё сложнее, а разработчики чаще нуждались в данных с других доменов. Однако браузеры строго придерживались политики одного источника (Same-Origin Policy, SOP), запрещавшей доступ к сторонним ресурсам. Эта политика появилась ещё в 1995 году в Netscape Navigator 2.0 и была призвана защитить пользователей от атак вроде XSS. Проблема в том, что SOP блокировала не только вредоносные, но и вполне легитимные запросы, например, к внешним API. Разработчики пытались обойти ограничения с помощью JSONP или iframe, но такие решения были небезопасными и нестабильными.

В 2005 году инженер Мэтт Ошри предложил идею более надёжного и безопасного механизма, который в дальнейшем стал основой CORS. А в 2008-м Анн ван Кестерен подготовила черновик спецификации для W3C. В 2014 году CORS официально вошёл в стандарт Fetch API и с тех пор стал ключевым элементом работы с кросс-доменными запросами. Он помогает контролировать доступ к ресурсам, сохраняя баланс между открытостью веба и безопасностью пользователей.

Как устроен CORS

CORS работает как диалог между браузером и сервером, основанный на HTTP-заголовках. Когда фронтенд-приложение (например, на сайте frontend.com) запрашивает данные с другого домена (api.com), браузер автоматически добавляет к запросу заголовок Origin: https://frontend.com. Этот заголовок сообщает серверу, откуда пришёл запрос.

Сервер в ответ решает, разрешать ли доступ. Если он включает в ответ заголовок Access-Control-Allow-Origin и указывает там адрес запроса (например, https://frontend.com) или символ * (разрешение для всех доменов), то браузер пропускает ответ. Если такого заголовка нет или значение не совпадает, браузер блокирует ответ — даже если сервер технически его отправил.

Для так называемых «сложных» запросов, например, с методом POST или нестандартными заголовками, браузер сначала отправляет предварительный (OPTIONS) запрос, чтобы уточнить у сервера, допустим ли основной. В ответе сервер указывает, какие методы (Access-Control-Allow-Methods) и заголовки (Access-Control-Allow-Headers) разрешены.

Пример ответа сервера с разрешением:

Топ-7 самых частых ошибок в CORS и как их исправить

Для того чтобы определить оптимальные методы работы, лучше учиться на ошибках. Хорошая новость в том, что почти все CORS-ошибки легко понять и исправить — если знать, где искать. Ниже собрали 7 самых распространённых ошибок CORS, с которыми сталкиваются разработчики, и рассказали, как можно с ними справиться без боли и паники.

Нет заголовка Access-Control-Allow-Origin

Сообщение об ошибке:

"No ‘Access-Control-Allow-Origin’ header is present on the requested resource"

Когда ваш JavaScript-код пытается получить данные с другого домена, браузер ожидает, что в ответе будет заголовок Access-Control-Allow-Origin. Если его нет — браузер блокирует ответ, считая его небезопасным.

Решение 1: Настроить сервер на разрешение CORS

Если вы контролируете сервер, добавьте в ответ заголовок:

Access-Control-Allow-Origin: *

* — разрешение запросов с любого домена

Но для безопасности лучше указать конкретный домен:

Access-Control-Allow-Origin: http://example.com

Решение 2: middleware CORS в Express.js

Если вы используете Node.js с Express, добавьте:

Браузер блокирует preflight-запросы (OPTIONS)

Сообщение об ошибке:

"CORS policy preflight request did not succeed" или что-то похожее.

Иногда перед настоящим запросом браузер сначала отправляет preflight-запрос методом OPTIONS, чтобы проверить, разрешен ли основной запрос. Это происходит, если:

• Метод запроса не GET или POST (например, PUT, DELETE).

• В заголовках есть что-то нестандартное (например, Authorization или Content-Type: application/json).

Если сервер не умеет обрабатывать OPTIONS — все ломается.

Решение: Обработать OPTIONS-запросы на сервере

Пример для Express.js:

app.options('*', cors()); // Разрешаем preflight-запросы

Или настройка CORS с поддержкой OPTIONS:

Запросы с учётом сессий (credentials) блокируются

Сообщение об ошибке:

"The value of the ‘Access-Control-Allow-Origin’ header in the response must not be '*' when the request's credentials mode is 'include'"

Вы отправляете запрос с куками или авторизацией (credentials: 'include'), но сервер разрешает доступ всем (Access-Control-Allow-Origin: *). Это запрещено — нельзя слать credentials, если разрешено всем.

Решение: Указать конкретный домен и разрешить credentials

На сервере также добавьте:

Access-Control-Allow-Credentials: true

Смешанные протоколы — HTTP и HTTPS

Сообщение об ошибке:

"Mixed content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'."

Ваш сайт работает по HTTPS, а API — по HTTP. Браузеры считают, что это опасно, и банально блокируют запросы.

Решение:

• Переведите API на HTTPS.
• Обновите все ссылки с http:// на https://.

• Если работаете локально и сервер только HTTP, используйте ngrok, чтобы создать HTTPS-туннель.

CORS блокирует редиректы

Сообщение об ошибке:

"Redirect from '...api' to '...login' has been blocked by CORS policy."

API делает редирект, но в ответе на редирект нет CORS-заголовков. Браузер не знает, можно ли доверять редиректу, и блокирует.

Решение:

Убедитесь, что редирект тоже возвращает правильные заголовки:

Access-Control-Allow-Origin: http://example.com

Если используете fetch, добавьте:

Неверно настроен Access-Control-Allow-Headers

Сообщение об ошибке:

"Request header field <X> is not allowed by Access-Control-Allow-Headers"

Ваш запрос содержит нестандартный заголовок (например, Authorization), а сервер не пропускает его.

Решение:

На сервере укажите, какие заголовки разрешены:

Метод запроса запрещён сервером

Сообщение об ошибке:

"Method PUT is not allowed by Access-Control-Allow-Methods"

Вы отправляете запрос методом PUT, PATCH, DELETE, а сервер разрешает только GET и POST.

Решение:

На сервере явно разрешите нужные методы:

• Как настроить подключение к SMTP-серверу?
• Что делать, если письма летят в спам?
• Как отправить HTML-письмо, чтобы вёрстку не перекосило?

После прочтения статьи вы научитесь создавать простые текстовые уведомления и HTML-письма с вложениями. Рассмотрим настройку SMTP-провайдера Яндекс, научимся слать письма с персональными вложениями.

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

SMTP — простой протокол передачи email

По протоколу SMTP почтовые серверы «договариваются» о передаче писем от отправителя к получателю. Архитектура проверена десятилетиями: каждый почтовый сервер в мире понимает SMTP. Протокол справляется с миллиардами писем ежедневно, не принадлежит ни одной компании, а новые решения не ломают старые системы.

Как работает SMTP

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

В электронной почте происходит нечто похожее:

1. Когда написали письмо и нажимаете «Отправить», ваша программа соединяется с SMTP-сервером.
2. Сервер проверяет адрес получателя и определяет, куда дальше передавать письмо.
3. Письмо путешествует между SMTP-серверами, пока не достигнет сервера получателя.
4. Сервер получателя сохраняет письмо в почтовый ящик, откуда адресат может его прочитать.

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

SMTP отвечает только за отправку писем. Он работает как «исходящая почта», передавая письма от отправителя к серверу получателя. SMTP используют, когда отправляют письма из приложений.

POP3 и IMAP предназначены только для получения писем. Они работают как «входящая почта» и позволяют клиентам загружать письма с сервера. Разница между ними в том, что POP3 скачивает и удаляет письма с сервера, а IMAP синхронизирует состояние писем между всеми устройствами пользователя.

Основные типы SMTP-серверов

По назначению SMTP-серверы можно разделить на две большие группы:

• Обычные серверы для переписки. Их предоставляют интернет-провайдеры, хостинг-компании и почтовые сервисы. Единственная проблема — лимиты. Можно отправлять не более 100-500 писем в день.
• Специальные серверы для массовых рассылок и автоматических уведомлений от сайтов (например, подтверждение регистрации или чек покупки). Через такие серверы можно отправлять тысячи и даже миллионы писем без риска блокировки.

Выбор зависит от ваших потребностей. Отправлять десятки писем в день можно через бесплатные сервисы: Gmail или Яндекс. Если планируете рассылки из сотен или тысяч писем, обратите внимание на SendGrid, Mailgun, Amazon SES. Они гарантируют защиту от блокировок, но работают по платной подписке.

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

Установка и настройка nodemailer

Практиковаться будем на бесплатной библиотеке Nodemailer. Через неё можно слать обычный текст и HTML-письма со сложным дизайном, вложенными файлами.

Перед установкой потребуется Node.js версии 8.0.0 или выше:

Если среда Node.js не установлена или устарела, скачайте актуальную версию.

Чтобы загрузить Nodemailer, откройте терминал, перейдите в директорию проекта и выполните команду:

Тестовый скрипт для отправки письма

Не беспокойтесь, если не определились с почтовым сервером. Отправим первое письмо в тестовом режиме — результат видно без реальной отправки.

Создайте новый файл, например send-email.js, и вставьте следующий код:

Запустите скрипт:

В консоли будет сообщение об успешной отправке и ссылка, по которой можно посмотреть, как выглядит ваше письмо. После подключения к реальному SMTP-серверу тестовые сообщения можно слать на личную или временную почту (Temp Mail, Internxt).

Подробнее по теме: Что такое временная почта и как ее использовать.

Отправка простого текстового письма

Код для отправки через SMTP-сервер Яндекса:

В user указываем логин от почты без @yandex.ru, а пароль нужно сгенерировать в Яндекс ID.

Поле from можно указывать в нескольких форматах:

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

Различие между cc и bcc

CC (Carbon Copy) — открытая копия письма. Все получатели видят адреса в поле cc:

BCC (Blind Carbon Copy) — скрытая копия. Получатели в bcc не видны другим адресатам:

Настройка reply-to

Если хотите получать ответы на другой адрес, используйте replyTo:

Создание и отправка HTML-писем

Самый простой способ отправить текст с применением стилей — передать HTML-код в виде строки:

HTML-код реальных писем сложнее, занимает сотни строчек. Поэтому рекомендуется использовать встроенный модуль fs для чтения из файла:

Встраивание изображений

Nodemailer поддерживает 2 способа работы с картинками:

• Ссылки на внешние ресурсы, которые загружаются при открытии письма.
• Встраивание картинки прямо в письмо через параметр attachments с флагом cid.

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

Адаптив и совместимость

Вёрстка в почтовых клиентах не работает как в браузерах. Многие CSS-свойства не поддерживаются, JavaScript полностью заблокирован.

HTML-письмо — это большая таблица, которая тоже состоит из таблиц.

Раньше таблицами верстали сайты, потом пришли к flexbox и grid. Электронная почта тоже эволюционирует, но медленно — в HTML-письмах эффективна только табличная вёрстка.

Таблицы корректно отображаться в Gmail, Mail.ru, Outlook и других почтовых клиентах.

Тестирование писем

Для проверки используйте:

• Litmus — платформа для тестирования в 90+ клиентах.
• Email on Acid — альтернатива Litmus.
• Mail Tester — бесплатная проверка на спам.
• Can I Email — таблица поддержки CSS в письмах.

Начинайте с простых шаблонов и постепенно усложняйте. Всегда тестируйте в основных клиентах: Gmail, Outlook и обязательно на мобильных устройствах.

Подключение шаблонов и вложений

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

При отправке 100 писем с приветствием «Привет, Максим!» и уникальными номерами заказов ручное создание HTML превращается в кошмар. Шаблонизатор Handlebars решает эту проблему. Также он упрощает поддержку — изменения в дизайне вносятся в один файл.

Handlebars превращает статичные HTML-шаблоны в динамические письма. Переменные заменяются реальными данными при компиляции.

Handlebars поддерживает условные блоки {{#if}} и циклы {{#each}}. С их помощью можно показывать разные части письма в зависимости от данных или выводить списки товаров, уведомлений, участников.

HTML-шаблоны реального проекта хранятся в отдельной папке. Модуль fs читает файл, Handlebars компилирует его с данными, результат передается в nodemailer. Такой подход разделяет логику приложения и вёрстку писем.

Добавление файлов-вложений

Параметр attachments в nodemailer принимает массив объектов с описанием файлов. Каждое вложение содержит имя файла и путь к нему или буфер с содержимым:

Размер всех вложений не должен превышать лимиты почтового сервера — 25 МБ для Gmail и Outlook.

Генерация файлов на лету

Популярная задача — создание PDF-документов прямо в коде. Библиотека pdfkit генерирует PDF в памяти, результат передается как буфер в nodemailer. Аналогично работают библиотеки для создания Excel-файлов или изображений. Получается персонализированное письмо с документами и красивым оформлением.

Ошибки при отправке писем и их обработка

Ошибки аутентификации встречаются чаще всего. Коды 535 и 534 указывают на проблемы с логином или паролем. Почтовые провайдеры требуют использования паролей приложений вместо основных паролей аккаунтов. Gmail и Яндекс.Почта не позволят войти с обычным паролем, если не включена 2-Fa.

Проблемы с получателями проявляются кодами 550 (пользователь не найден) и 553 (неверный формат email). Ошибка 552 сигнализирует о превышении размера письма.

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

Простейший подход — попытки отправки с увеличивающимися интервалами: 2, 4 и 8 секунд.

Как понять, дошло ли письмо?

Nodemailer сообщает только о том, что SMTP-сервер принял письмо для доставки. Это не гарантирует доставку в почтовый ящик получателя.

Фактическая доставка зависит от множества факторов:

• репутации отправителя,
• содержимого письма,
• настроек получателя.

Для отслеживания реальной доставки используют скрытый пиксель — невидимые изображения размером 1×1 px, встроенные в HTML-письма. Когда получатель открывает письмо, изображение загружается с вашего сервера, фиксируя факт прочтения.

Почему письма попадают в спам?

Спам-фильтры анализируют множество факторов. Основные проблемы: отправка с бесплатных почтовых сервисов для бизнес-рассылок, использование спам-слов в теме (“СРОЧНО!!!”, “СКИДКА 90%”).

Технические аспекты:

• отсутствие SPF, DKIM и DMARC записей в DNS;
• неправильно настроенный reverse DNS;
• высокий процент отказов (bounce rate) в предыдущих рассылках.

Хотите улучшить доставляемость? Добавьте ссылку для отписки, поддерживайте чистоту списков рассылки и наращивайте объем писем постепенно.

Безопасность при отправке писем

Первое правило: никогда не храните пароли прямо в коде. Даже если это тестовый проект, который никто не увидит. Используйте переменные окружения.

Создайте файл .env в корне проекта:

Не забудьте добавить .env в .gitignore. В коде обращайтесь к этим переменным через process.env:

OAuth2 и пароли приложений

Если работаете с Gmail, Яндексом или другими крупными почтовыми сервисами, забудьте про обычные пароли. Используйте OAuth2 или пароли для приложений:

• Пароли приложений работают только для конкретной задачи, их можно в любой момент отозвать.
• OAuth2 — более сложный, но безопасный способ.

Подробнее по теме: OAuth 2.0 и OIDC: как защитить API и пользовательские данные.

SPF, DKIM, DMARC

Это записи в DNS, которые говорят почтовым серверам: «Да, это письмо действительно от нас, а не от мошенников»:

• SPF — список IP-адресов, с которых можно отправлять письма от вашего домена.
• DKIM — цифровая подпись письма.
• DMARC — политика обработки писем, которые не прошли проверку.

Если используете свой домен, настройте эти записи. Если нет — не переживайте, это задача для более продвинутого уровня.

Что дальше?

Следующий шаг — автоматизация рассылок. Когда пользователь регистрируется, система отправляет приветственное письмо, при оформлении заказа — подтверждение с деталями покупки.

Для больших объёмов писем понадобятся SendGrid, Mailgun и Amazon SES. Эти сервисы решают проблемы с доставляемостью и предоставляют статистику — сколько писем доставлено, открыто, по каким ссылкам кликнули получатели.

Персонализация выходит за рамки подстановки имени в шаблон. Анализ поведения пользователей позволяет отправлять релевантный контент — подборки товаров на основе предыдущих покупок, напоминания о брошенной корзине.

Тестирование email-кампаний помогает улучшить результаты. A/B-тесты показывают, какие заголовки чаще открывают, эксперименты с временем отправки выявляют оптимальные часы для конкретной аудитории.

Интеграция с аналитикой замыкает цикл. UTM-метки в ссылках письма показывают в Google Analytics, сколько пользователей перешло из рассылки на сайт и что там делали. Эти данные помогают оценить эффективность email-маркетинга и планировать следующие кампании.

Сделайте минимальный Docker-образ, не ломая прод

Большинство Docker-образов в проектах содержат больше данных, зависимостей и инструментов, чем требуется для работы приложения. Это приводит к избыточному объёму, медленной сборке и повышенным рискам безопасности. Умение собирать минимальный образ — один из базовых навыков работы с Docker, который напрямую влияет на стабильность и скорость развёртывания.

Начать стоит с multi-stage сборки: на первом этапе — установка зависимостей и сборка, на втором — только нужные артефакты. Это позволяет исключить лишние файлы и утилиты из финального образа. В качестве базового слоя лучше использовать alpine, distroless или даже scratch, если вы точно понимаете, какие бинарники и библиотеки требуются приложению.

Хорошая практика — использовать утилиты docker history и dive для анализа того, какие файлы и слои попали в образ. Если размер превышает ожидания, стоит проверить, не остались ли во внутреннем слое временные файлы, dev-зависимости или директории кэша.

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

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

Попробуйте контейнизировать то, что изначально не предназначалось для этого

Работа с Docker чаще всего начинается с бэкенд-приложений, сервисов и утилит, которые изначально проектировались как самостоятельные процессы. Они хорошо вписываются в модель контейнеров: запускаются из CLI, работают в изоляции, не требуют доступа к UI или железу. Но стоит выйти за эти рамки — начинаются сложности.

Попробуйте упаковать в контейнер любую графическую программу. Технически это возможно: X11 или Wayland можно пробросить через сокет, устройства передать через volume, окружение прописать вручную. Но на практике вы столкнётесь с рядом ограничений: отсутствие звука, глюки интерфейса, ошибки в драйверах, проблемы с доступом к GPU или нестабильное поведение при рендеринге.

В этом упражнении ценен не сам результат, а путь. Вы увидите, как устроена изоляция в Docker, почему графические приложения не работают «из коробки» и где находятся реальные границы контейнеризации. Контейнер — это не виртуальная машина, у него нет полноценного init, драйверов или прямого доступа к оборудованию. Многие фичи, которые работают локально, в контейнере требуют дополнительных танцев с бубном.

Такая практика особенно полезна, если вы имеете дело с devtool'ами, UI-обвязкой или тестированием в headless-средах. Понимание, что именно ломается и почему, позволяет более точно проектировать окружение и избегать архитектурных ловушек в будущем.

Соберите базовый образ с нуля

Когда разработчик пишет FROM node или FROM ubuntu, он автоматически получает десятки слоёв, библиотек и утилит, о которых, скорее всего, не задумывается. Это удобно, но не даёт понимания, как вообще работает контейнер на низком уровне. Попробуем разобраться.

Укажите в Dockerfile FROM scratch — и не увидите ни bash, ни glibc, ни стандартных каталогов. Вам придётся самостоятельно добавить всё необходимое: бинарник, зависимости, библиотеки, конфигурацию. Если пишете на Go, задача упрощается: можно собрать статически слинкованный исполняемый файл и скопировать его в образ. Для других языков, особенно тех, что зависят от динамических библиотек или рантайма (например, Python или Node.js), придётся вручную подтягивать зависимости.

Такая практика заставляет иначе взглянуть на структуру контейнера. Вы начнёте понимать, чем отличается CMD от ENTRYPOINT, зачем в некоторых образах используется sh -c, и что произойдёт, если не задать WORKDIR. Вы столкнётесь с ошибками «no such file or directory» даже тогда, когда файл вроде бы существует — потому что в контейнере не хватает нужной libc.

Отдельный повод для размышлений — Alpine. Его любят за размер и минимализм, но он использует musl вместо glibc, и не всё с ним работает корректно. В процессе сборки на практике увидите, почему иногда проще остаться на Debian Slim, чем пытаться адаптировать всё под Alpine.

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

Делайте разные варианты Docker-образов

Хороший Dockerfile — тот, который гибко адаптируется под разные сценарии: продакшен, отладку, тестирование, запуск на ARM или x86. Если вы умеете собирать только один универсальный образ — вы ещё не освоили Docker по-настоящему.

Попробуйте собрать сразу несколько версий своего образа: на Debian и на Alpine, с минимальным размером и с полным набором утилит, для amd64 и arm64. Добавьте build-аргументы (ARG) — они позволяют передавать параметры на этапе сборки: выбрать базовый образ, включить или выключить зависимости, задать переменные окружения. Используйте RUN if или шаблонизацию через Dockerfile.template, чтобы варьировать поведение без дублирования кода.

Вот типичный пример: в режиме отладки вам нужен образ с установленным curl, vim, доступом к логам и расширенной трассировкой. А в продакшене — максимально облегчённый, с удалёнными временными файлами, сжатым слоем и только необходимыми бинарниками. Один и тот же проект — два разных образа. Добавьте сюда ещё поддержку разных архитектур (multi-arch build через --platform), и вы выйдете на уровень CI/CD, где из одного пайплайна собирается три-четыре артефакта.

Такая практика решает сразу несколько задач. Во-первых, помогает лучше понять, как влияет каждый шаг сборки на финальный размер и поведение контейнера. Во-вторых, избавляет от лишних костылей, когда на проде всё работает, а на локалке — нет. И главное — прокачивает навык автоматизации. Один Dockerfile, разные образы, ноль копипасты.

Поиграйте в «А что если запустить чужой (небезопасный) код?»

Представьте задачу: вам нужно запустить код, который написал кто-то другой. Вы не уверены, что он безопасен. Это может быть скомпилированный бинарник, питоновский скрипт или даже npm-зависимость с подозрительным хуком. Где-то в коде может быть rm -rf /, попытка выйти за пределы контейнера, установить рутовый доступ или просто майнить крипту. И теперь этот код запускается на вашей машине — внутри Docker.

Кажется, контейнер защитит? Не всегда.

Docker не является полноценной песочницей. По умолчанию контейнер может обращаться к файловой системе, к ядру и к хостовым ресурсам — особенно если вы запускаете его с --privileged или без ограничения пользователя. Даже docker run -it ubuntu работает от root внутри контейнера, что уже создаёт риски.

Если вы действительно хотите запустить небезопасный код, нужно жёстко ограничить контейнер:

• отключить права root (через --user);

• запретить модификацию файловой системы (--read-only);

• отобрать лишние возможности ядра (--cap-drop=ALL);

• включить seccomp-профиль, AppArmor или SELinux;

• отключить доступ к сети или монтированию сокетов.

Список можно продолжать. Главное — понять, что Docker по умолчанию не даёт изоляции на уровне VM. Если вы работаете с кодом, которому не доверяете, этого может быть недостаточно.

Это упражнение учит думать о безопасности как о процессе. И особенно важно пройти его, если вы когда-нибудь планируете запускать user-generated code: плагины, кастомные скрипты, пайплайны CI. Только на практике становится ясно, где заканчиваются возможности Docker и начинаются границы настоящей песочницы.

Работайте без Docker CLI

Если убрать Docker CLI — что останется? Больше, чем кажется.

Docker ― это не единый монолит. Он работает поверх набора инструментов и стандартов: buildkit, containerd, спецификация OCI. CLI просто прячет эту архитектуру за удобными командами: docker build, docker run, docker push. Но всё, что кажется магией, можно повторить вручную.

Попробуйте отказаться от docker как от инструмента. Сконфигурируйте buildctl напрямую и соберите образ без Dockerfile. Или вообще создайте его вручную: сформируйте структуру, описания слоёв, метаданные, манифест. Прочитайте спецификацию OCI Image Format и идите по ее шагам. Понадобится tar, sha256sum, немного JSON — и внимательность.

Образ собрали? Отлично. Теперь отправьте его в реестр без docker push. Используйте oras, skopeo или curl с аутентификацией и ручной отправкой слоёв по HTTP API. Узнаете много нового: как работает digest, что такое manifest list и зачем нужны media types.

Наконец, запустите контейнер без docker run. Через ctr, runc или даже напрямую с помощью systemd-nspawn.

Зачем это нужно? Чтобы воспринимать Docker глубже. Так, вы понимаете, как устроен pipeline сборки и запуск контейнера, и точнее управляете им. Особенно это важно в продакшн-среде: когда образы не собираются, push падает, реестр отвечает 403, а пайплайн горит.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Инструменты и окружение

Современные DevOps-инженеры без инструментов — как админ без терминала. Вот что стоит добавить в стек:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — Список лучших инструментов для DevOps-инженеров, которые упрощают релизы, мониторинг и CI/CD-процессы. От логгирования до автоматизации тестов.

Podman: Альтернатива Docker без daemon — Знакомим с Podman, инструментом, который не требует daemon, но дает весь функционал Docker.

Docker Hub в России — всё? Гайд, как обойти блокировку —Объясняем, как работать с Docker Hub после блокировки: альтернативы, зеркала и решения.

CI/CD, Kubernetes и деплой

Когда каждое изменение должно доходить до продакшена быстро и без боли — нужна хорошая сборка:

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Практическое руководство по внедрению и настройке CI/CD: инструменты, примеры, лайфхаки.

Собираем и деплоим в Kubernetes приложение на Node.js с помощью werf — Пошагово показываем, как собрать и развернуть приложение на Node.js в Kubernetes с помощью инструмента werf.

Как автоматизировать деплой с использованием Kubernetes — Рассказываем, как автоматизировать процесс деплоя приложений в Kubernetes: подходы, инструменты и советы.

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

Практики и подходы

Не только инструменты, но и культура разработки — основа DevOps:

Как стать DevOps в 2024 году — Что нужно знать, какие навыки прокачивать, с чего начать.

Как автоматизировать безопасность с помощью DevSecOps и искусственного интеллекта — Объясняем, как применить DevSecOps-подход и AI для защиты приложений на всех этапах разработки.

Как serverless-технологии помогают снизить нагрузку на разработчиков — Разбираемся, как serverless помогает ускорить разработку, упростить масштабирование и снизить поддержку инфраструктуры.

Не забывайте читать предыдущие гайды. Python, React, мобильная разработка, С++, инструменты, фронтенд.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

База и теория

1. Event loop для чайников: простыми словами о сложном механизме браузера — В статье разбираем, что такое Event Loop, очередь задач и стек вызовов. Простыми словами о том, как браузер выполняет JavaScript-код и обрабатывает события.
2. Чек-лист по Node.js для новичков: обработка ошибок — Показываем основные подходы к обработке ошибок для Node.js. Рассматриваем пошаговую инструкцию и практические примеры.
3. Что нужно учить JavaSript-разработчикам в 2024 году — Разбираем, какие технологии и навыки нужно знать JS-разработчику, в том числе и в 2025. От фреймворков до подходов к архитектуре.
4. Декларативные языки на примерах с JavaScript — Рассказываем, что значит декларативный стиль программирования. Сравниваем с императивным на примерах JavaScript.
5. JavaScript localStorage: Полное руководство — Разбираем, как работает localStorage. Учим сохранять данные на клиенте с помощью JavaScript.
6. Как работает режим strict в JavaScript — Объясняем, что делает режим strict и почему он помогает писать более безопасный код на JavaScript.
7. Как бесплатно выучить JavaScript и не идти в онлайн-школы — Рассказываем, как самостоятельно освоить JavaScript. Бесплатные ресурсы, полезные советы и личный план обучения.
8. Какие JS-библиотеки использовать для анимаций на сайте в 2024 году — Актуальные JavaScript-библиотеки для веб-анимации. Рассматриваем лучшие инструменты для красивых и быстрых интерфейсов.

Практикуемся

1. 10 реальных вопросов с собеседования JavaScript-разработчика с ответами — Подборка реальных вопросов с собеседований для JavaScript-разработчиков. Даем ответы и объясняем, как правильно мыслить на интервью.
2. Приложение прогноза погоды с использованием Vue JS — Пошаговое руководство по созданию погодного приложения на Vue.js. Обучаем взаимодействию с API и построению интерфейса.
3. Математика в программировании: реализуем уравнения на JavaScript — Объясняем, как реализовать математические уравнения на JavaScript. Практика для программистов, которые не боятся формул.
4. Регулярные выражения в JavaScript: разбираемся в создании — Учим создавать и использовать RegExp в JavaScript. Поясняем синтаксис, паттерны и типовые ошибки.
5. Решаем популярные задачи с асинхронным кодом на JavaScript: часть первая — Практика асинхронного программирования на JavaScript. Решаем задачи с API, задержками и промисами.
6. Асинхронный JavaScript: изучаем Async/Await, Callbacks и Promises — Учим писать асинхронный код в JavaScript: от колбэков до современного async/await. Понятно, на примерах и без лишнего.
7. Задачи по асинхронному программированию на JS — Упражнения на асинхронный JavaScript. От простых примеров до сложных сценариев.

Предыдущие подборки лежат здесь: React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Оскар — разработчик с 18-летним стажем. Он решил разобраться, насколько утверждение про необходимость знать множество языков правдива.

Сам Оскар за свою карьеру успел поработать с C#, Java, C++, Python, Ruby, JavaScript, Perl и прочими языками. Но не потому что стремился к полиглотству, а потому что так сложилось — проекты, клиенты, задачи.

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

Синтаксис — это не все

Проблема в том, что многие изучают новый язык на уровне «выучил синтаксис — значит, могу писать». Но это часто приводит к «Java-коду на Go» или «C#-архитектуре в TypeScript». Новички в языке переносят привычные паттерны, не понимая, как использовать сильные стороны новой платформы.

Чтобы писать идиоматично, нужно время. Неделя — чтобы освоить синтаксис. Пару месяцев — чтобы почувствовать экосистему. Год — чтобы писать как носитель языка.

Когда стоит добавлять новый язык в стек

Оскар выделяет три повода:

• Бизнес-задача. Например, для тяжелых расчетов стоит взять язык быстрее JavaScript.
• Кадровый вопрос. Иногда проще найти разработчиков под Node.js, чем под Java.
• Карьерный рост. Умение работать с востребованным стеком открывает больше возможностей.

Но главное — не делать выбор из любопытства. Однажды Оскару пришлось переписать модуль с F# на C#, потому что никто не хотел его поддерживать. В другом проекте Python-модуль оказался узким горлышком и потребовал переделки. Эти эксперименты дорого обошлись бизнесу.

Архитектору — особенно важно

Если вы архитектор, то знание языков — не просто плюс, а необходимость. Без этого вы будете опираться на чужие слова и чужие слайды, а не на собственный опыт. Лучшие архитекторы, по словам Оскара, регулярно пишут код — пусть и не фуллтайм.

Баланс между глубиной и гибкостью

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

Языки — это инструменты. Хороший разработчик остается таковым вне зависимости от того, на чем он пишет.

Причины переноса сайта на другой хостинг могут быть разными:

• Юзабилити. Страницы сайта начнут грузиться быстрее, плюс он будет более удобным и поднимется в поиске.
• Затраты. Хостеры с выгодными тарифами или оптимальными предложениями позволят снизить эксплуатационные расходы.
• Стабильность. Смена провайдера с частыми сбоями на более устойчивого партнера обеспечит бесперебойную работу ресурса.
• Поддержка. Более квалифицированная служба поддержки поможет быстрее справляться с возникающими проблемами;
• Масштабирование. Хостер с возможностью масштабирования ресурсов поддержит растущий трафик и потребности вашего сайта;
• Безопасность. Повышенные меры защиты предотвратят угрозы кибератак и утечек данных;
• Расположение. Серверы, расположенные рядом с основной аудиторией, обеспечат ускоренную загрузку и лучшее восприятие пользователями.

Какой бы ни была причина перехода, важно организовать его без потерь данных и времени.

Шаг первый

Начать стоит с планирования и подготовки к миграции. Выберите оптимальное время для переезда. Запланируйте перенос на наименее загруженный период работы сайта (например, поздней ночью или в выходные). Одновременно с этим приостановите публикацию нового контента и изменения на странице на время миграции, и предупредите команду, чтобы редакторы, авторы или клиенты не вносили правки: любые изменения во время переноса могут не попасть на новый сервер, что приведёт к потере данных. Если ожидается заметный простой или отключение функций (например, оформление заказов), предупредите пользователей о предстоящих технических работах. Разместите баннер или уведомление на сайте с указанием времени обслуживания и извинениями за неудобства.

При переносе необходимо подготовить новую хостинг-платформу заранее: зарегистрировать и настроить аккаунт у нового провайдера — желательно за 1-2 недели до переключения. Важно, чтобы тариф и ресурсы нового хостинга не уступали старому, а лучше превосходили его по параметрам (производительность, объем хранилища, оперативная память и пр.). Обязательно стоит проверить совместимость нового сервера с имеющимся стеком технологий: версии ОС, PHP/Node.js, СУБД, требуемые модули и библиотеки должны соответствовать или превышать текущие, чтобы избежать ошибок совместимости.

Далее нужно провести аудит всех компонентов вашего проекта. Составьте подробный список того, что нужно перенести: файлы сайта, базы данных, аккаунты пользователей, контент (изображения, видео, документы), настроенные задачи (cron jobs), DNS-записи (A, CNAME, MX и пр.), сертификаты SSL, иные интеграции.

Заранее стоит продумать, как минимизировать downtime. Помимо выбора ночного времени и контент-фриза существуют технические приемы: например, сокращение TTL DNS (см. раздел про DNS ниже) позволяет быстрее переключить домен на новый IP, а предварительное тестирование сайта на новом сервере до обновления DNS помогает выявлять проблемы — причем пользователи ничего не заметят.

Шаг второй

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

Шаг третий

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

Далее — скопировать файлы сайта на новый сервер. Самый простой способ — загрузить бэкап на новый хост и развернуть его там, после чего перенести на него базу данных, связанные сервисы и настройки. Помимо основного кода и БД, переносится и все окружение сайта. До переключения DNS запускаем тестирование на новом сервере, чтобы убедиться в работоспособности сайта в новом окружении, прежде чем направлять на него пользователей.

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

Шаг четвертый

Чтобы сократить TTL DNS перед переключением, за день-два до планируемой миграции стоит уменьшить TTL (Time to Live) для DNS-записей вашего домена, а также обновить DNS-записи на новые. Когда новый сервер полностью готов и протестирован, нужно изменить DNS-записи домена, указывающие на старый хост, чтобы они указывали на новый. Если домен обслуживается у регистратора или внешнего DNS-сервиса — поменяйте A-запись (IPv4) и AAAA-запись (IPv6), или NS-записи (если менялся DNS-провайдера целиком). В случае смены хостинга часто требуется обновить NS (nameservers) на стороне регистратора на NS нового провайдера.

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

После проверки переноса или перенастройки всех связанных DNS-записей стоит проверить и обновления DNS. Для этого можно использовать утилиты вроде nslookup или онлайн-сервисы (Google DNS, Cloudflare DNS, WhatsMyDNS), чтобы убедиться, что домен теперь указывает на новый сервер по всему миру.

Шаг пятый

Перенос состоялся. Что дальше? Пост-миграционное тестирование и мониторинг

В рамках этих процессов необходимо тщательно проверить сайт на новом хостинге. Когда домен начал вести на новый сервер, стоит провести всестороннее тестирование фронтенда и бэкенда в боевых условиях: при помощи инструментов веб-аналитики или специальных сервисов для измерения скорости сравнить время загрузки страниц до и после переезда. Это нужно для оценки производительности и нагрузки.

Не стоит забывать следить за журналами и метриками: просматривать логи веб-сервера и приложений на новом сервере, искать ошибки (PHP fatal errors, 500 Internal Server Error, проблемы подключения к БД и т.д.) и устранять их. После перехода на новый хостинг нужно проверять и SEO-показатели и индексацию, чтобы убедиться, что сайт по-прежнему правильно индексируется поисковиками.

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

Лайфхаки для безопасной и простой миграции

Вот несколько универсальных советов для тех, кто планирует переезжать на новый хостинг:

• Делайте бэкапы на каждом этапе.
• Планируйте и документируйте. Подготовьте чек-лист миграции и строго ему следуйте.
• Тщательно проверяйте окружение до запуска. Никогда не переключайте пользователей на новый хостинг, пока сами не убедитесь, что там всё работает на 100%.
• Минимизируйте окно простоя.
• Общайтесь с аудиторией. Предупредите постоянных пользователей о небольшом перерыве в работе.
• Учитывайте SEO-факторы. Небольшие просадки SEO в возможны, но правильная миграция их минимизирует.
• Следите за качеством данных. После переезда организуйте своеобразный аудит данных: сопоставьте количество записей в базах, количество файлов, размер медиа-библиотеки до и после.

Не отключайте старое раньше времени. Мы уже упоминали, но повторим: пусть старый хостинг побудет вашей сетью безопасности на случай форс-мажора. Лучше заплатить за лишние несколько дней или неделю, чем потом пожалеть о поспешном удалении данных.

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

Ниже — оставшиеся три паттерна, которые мы не разобрали в прошлой статье.

Хуки и кастомные хуки

Мы уже несколько раз упоминали хуки (Hooks) — пора поговорить о них как о новом паттерне, фактически пришедшем на смену многим предыдущим. Хуки появились в React 16.8 и моментально изменили стиль написания компонентов. Теперь вместо классов с методами жизненного цикла у нас функциональные компоненты, которые используют состояния (useState), эффекты (useEffect) и другие возможности прямо внутри функции. А главное — мы можем писать свои собственные, пользовательские хуки (custom hooks) для повторного использования логики.

Почему же хуки так популярны? Они дают возможность переиспользовать состояние и побочные эффекты, не меняя структуру самих компонентов. Раньше, чтобы два компонента разделяли какую-то логику, приходилось применять HOC или Render Props — то есть вводить дополнительный компонент-обёртку или коллбэк. Теперь же мы можем вынести логику в custom hook useSomething() и вызвать его в нужных нам компонентах или других кастомных хуках. Получается, что хуки позволяют писать более прямолинейный, читаемый код: вместо закулисной магии HOC мы явно вызываем необходимые нам хуки и получаем данные.

Custom hook — это просто функция, название которой по соглашению начинается с use (чтобы линтер React знал, что внутри неё могут быть хуки). Например, давайте перепишем наш HOC withCounter из предыдущего примера как кастомный хук:

Получилось то же самое поведение (счётчик кликов), но без обёрток. Компонент ClickButton сам вызывает useCounter() и получает count и increment. Внутри useCounter может быть любая другая сложная логика, побочные эффекты, вызовы других хуков — компонент, использующий наш хук, об этом не знает и не должен знать. Зато код компонента предельно ясный: он просто берёт нужные ему данные из хука и использует их.

Повторное использование логики — главное преимущество кастомных хуков. Вы можете написать, например, хук useFetch(url) (достаточно распространённое решение), который будет обращаться к API и возвращать состояние загрузки, успеха запроса, данные и ошибки. Далее можно применять этот хук в разных компонентах, страницах, не дублируя сам код запроса.

Кроме того, хуки отлично работают друг с другом. Вы можете внутри одного хука вызвать другой (например, использовать useContext или useReducer внутри своего useAuth хука). Это помогает облегчить написание сложных функциональностей, так как мы используем небольшие хуки, выполняющие простые задачи, из которых как конструктор составляем более сложное поведение.

Плюсы: ясность и лаконичность. Мы не оборачиваем компонент, использующий хук, ни в какие лишние слои, его JSX не замусорен вспомогательными функциями или компонентами, он просто вызывает хук и получает результаты. HOC и Render Props во многом ушли в прошлое из-за того, что хуки решают те же проблемы более естественным для JavaScript способом. Кастомные хуки легко тестировать (это по сути просто функции). Хуки позволяют разделять логику внутри одного компонента на независимые части: например, компонент может использовать одновременно и свой локальный useState, и несколько разных кастомных хуков — каждая часть отвечает за себя, и этот код не переплетается, тогда как при использовании нескольких HOC или Render Props было бы труднее изолировать ответственности.

Минусы: если это можно назвать минусом. Хотя хуки упростили многое, они принесли также свои правила, о которых нужно помнить: вызывать в одном порядке, только в компонентах либо других хуках, не внутри условий. Если нарушить эти правила, React выдаст предупреждение или ошибку. Ещё потенциальный минус: повторное использование хука означает, что каждый компонент получает свою копию состояния. Это обычно то, что нам нужно, но если вдруг требуется разделять одно состояние между несколькими компонентами — хуки напрямую не помогут, придётся выносить состояние выше (или в контекст, или в стор). Впрочем, это уже другая задача.

В целом, сейчас хуки — основной инструмент в React, используемый разработчиками. Большинство новых API, фреймворков, библиотек строятся вокруг хуков. Поэтому если вы видите библиотеку, написанную на HOC либо Render Props, то, скорее всего, у неё уже есть или появится версия на хуках. Хуки сделали код React компонентов более понятным и свели на нет необходимость в классах (почти все новые фичи React рассчитаны только на функциональные компоненты).

Compound Components (Составные компоненты)

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

Я познакомился с данным паттерном, когда писал в качестве пет-проекта свой собственный UI Kit. Представьте <Accordion> с множеством <AccordionItem> или <Select> и <Option>. Compound Components — когда мы пишем код таким образом, что компонент <Accordion> не обязан принимать массив пунктов через пропсы и рендерить его внутри. Мы даём разработчику возможность самому в JSX расписать, какие пункты будут у аккордеона и что в них будет находиться, используя заранее предусмотренные дочерние компоненты: <Accordion.Item>, <Accordion.Header> и <Accordion.Panel>.

Возможно, у вас, как и у меня, сразу же возник вопрос в голове: «как же Accordion узнает о своих Item и организует их работу?» Внутри — как раз при помощи React Context. Compound Components обычно реализуются так: родитель (компонент-контейнер) содержит всё состояние (например, какой пункт раскрыт) и методы управления (функция toggle(index)). Он оборачивает children своим контекст провайдером и передаёт туда эти данные и функции. Дочерние компоненты (которые рендерятся где-то внутри children) просто берут нужное из контекста и таким образом получают доступ к состоянию родителя. Они знают, к какому именно контейнеру принадлежат, благодаря тому, что рендерятся внутри него и получают его контекст.

Давайте рассмотрим конкретный пример. Сделаем простой составной компонент Toggle, который будет управлять отображением/скрытием некоторого контента по клику. У нас будет <Toggle> в роли контейнера и его дочерние компоненты <Toggle.On>, <Toggle.Off> и <Toggle.Button>.

Здесь <Toggle> управляет состоянием on (показано/скрыто) и предоставляет через контекст значение { on, toggle } всем потомкам. <ToggleOn> и <ToggleOff> читают on и в зависимости от него либо рендерят children, либо нет. <ToggleButton> получает из контекста функцию toggle и вызывает её при клике. В итоге снаружи мы получаем удобный и декларативный интерфейс: внутрь <Toggle> мы помещаем разные части UI, которые сами знают, когда им отображаться и что делать при клике — мы лишь описываем структуру, не связывая их вручную пропсами.

Обратите внимание: компоненту <Toggle> без разницы, сколько у него внутри <ToggleOn> или <ToggleOff> и какой внутри них JSX. Всё завязано только на состоянии контекста. Это и есть сила композиции: пользователю библиотеки даются «кирпичики» (несколько компонентов), из которых он может сложить нужную конструкцию как ему необходимо, а не один монолитный компонент с десятком пропсов настроек.

Плюсы этого паттерна: огромная гибкость и выразительность. Хороший compound-компонент ощущается как маленький фреймворк. Например, библиотека @reach/ui (предшественник современной radix-ui) много компонентов строила через этот паттерн: диалоги, списки, выпадающие меню . Пользователю легко понять API — просто вкладывай одни компоненты в другие. Появляется возможность тонко настроить итоговую разметку, вставить дополнительные элементы если надо, ведь внутри children мы не ограничены, можем обернуть тот же <ToggleButton> в какой-нибудь <div> с нужным классом. Проще поддерживать визуальное единообразие: все части контролируются одним контекстом, не размазывая логику по нескольким несвязанным компонентам.

Минусы: сложнее реализовать. Необходимо аккуратно продумать как компоненты будут взаимодействовать, предусмотреть, что некоторые могут отсутствовать или повторяться. Если неправильно спроектировать составной компонент, можно столкнуться с багами: например, если <ToggleButton> случайно использовать вне <Toggle> (то есть вне своего провайдера), useContext вернёт undefined и будет ошибка — надо либо избегать такого, либо делать проверки и бросать понятное сообщение об ошибке (мол, «ToggleButton ОБЯЗАТЕЛЬНО должен быть потомком Toggle»).

Ещё один момент связан с производительностью, когда контекстное значение меняется, все потребители контекста перерендерятся. Например, при каждом клике toggle выше перемонтируются и <ToggleOn>, и <ToggleOff>, и <ToggleButton>. В нашем случае это конечно пустяки, но если бы у нас был десяток сложных для ререндера children'ов, подписанных на контекст, и состояние менялось часто, нужно было бы подумать об оптимизации (разбивке контекстов или мемоизации).

Тем не менее плюсы обычно перевешивают: паттерн Compound Components позволяет создать очень понятный и гибкий пользовательский API для ваших компонентов. Это проявление философии React — композиция важнее наследования. Вместо того чтобы делать сложный компонент с кучей условий, мы делаем набор простых компонентов, которые в комбинации собираются в сложное поведение.

Compound Components — довольно «профессиональный» паттерн. В небольших приложениях вы можете не столкнуться с необходимостью его реализовывать, но если разрабатываете библиотеку компонентов, как я в своём пет-проекте, или сложный виджет, такой подход — чуть ли не необходимость. Практически все продвинутые React UI-библиотеки (Material UI, Chakra, Radix и т.д.) используют контекст и композицию под капотом для своих сложных компонентов.

Серверные компоненты и Suspense: современные возможности React

Наконец, давайте поговорим о новейших возможностях, которые принесли нам 18 и 19 версии React’а. Они направлены на улучшение работы с асинхронностью, данными и рендерингом на стороне сервера. В первую очередь, React Suspense и Server Components. Эти вещи ещё не до конца устоялись в среде разработчиков, но их стоит держать в уме.

Suspense — ожидание с комфортом

Когда интерфейсу нужно загрузить данные, всегда возникает задача — показать индикатор загрузки, пока всё не готово. Раньше приходилось вручную писать логику, часто это бывало состояние isLoading и условный рендер либо спиннера, либо контента. С появлением React Suspense командой React был предложен более декларативный способ. Suspense — это специальный компонент, который позволяет нам приостановить рендеринг своих дочерних компонентов, пока те не готовы, и в это время показать fallback UI.

Проще говоря, мы оборачиваем часть дерева компонентов в <Suspense fallback={<Loader/>}> ... </Suspense>, и если внутри этой области происходит задержка (например, идёт загрузка кода или данных), React сам автоматически покажет <Loader> вместо содержимого, а когда всё завершится — отобразит наши компоненты. Suspense берёт на себя координацию этого процесса, освобождая нас от ручного управления состоянием загрузки.

Сегодня Suspense широко используется для ленивой загрузки компонентов (React.lazy + <Suspense>). Например:

Здесь компонент Comments будет подгружён по требованию (и в отдельном бандле). Пока бандл не загрузится, пользователь увидит текст-заглушку «Комментарии загружаются...». Как только код придет, React отрисует <Comments>. Всё это без какого-либо специального кода внутри ArticlePage для отслеживания загрузки. Suspense сам разрулит ситуацию — React.lazy под капотом бросает Promise на время загрузки, а <Suspense> ловит его и показывает фоллбэк.

Кроме ленивой загрузки кода, Suspense постепенно начинает применяться и для асинхронных данных. В React 18 появился экспериментальный API, позволяющий Suspense работать с данными, например, можно использовать специальный use для ожидания промиса прямо внутри компонента (пока официально не стабильно, но фреймворки типа Next.js 13 уже вовсю используют это). Идея та же: компонент, который загружает данные, вместо того чтобы сразу вернуть JSX, может приостановить своё выполнение до получения данных. React, обнаружив это, покажет fallback, а когда данные придут — продолжит рендер компонента. Таким образом, можно писать компонент, который выглядит синхронным, хотя внутри у него асинхронный код — за счёт Suspense'а пользователю не покажется незавершённый результат.

Признаться, Suspense для работы с данными — пока штука из области экспериментов. Если вы пишете обычное приложение на Vite или CRA без Next, то прямо сейчас использовать Suspense для загрузки данных «из коробки» не выйдет — потребуется либо сторонняя библиотека (например, React Query пока не интегрирован с Suspense по умолчанию, но планирует), либо фреймворк. Однако направление понятное: React движется к тому, чтобы сделать работу с асинхронностью более декларативной. Уже сейчас вы можете использовать Suspense для спиннеров и заглушек при загрузке кода, а в ближайшем будущем, вероятно, подобный подход станет нормой и для данных (в React 19+ должны появиться официальные инструменты для этого).

Подводя итог по Suspense: этот паттерн позволяет очень аккуратно организовать отображение состояния загрузки. Вместо большого количества условных isLoading ? <Spinner> : <Content> мы просто заявляем: «Эта часть UI может задержаться, показывай пока вот это». Это улучшает UX (пользователь видит скелетон или лоадер без моргания незагруженного контента) и упрощает код. Обязательно следим за развитием Suspense — возможно, скоро он будет использоваться намного чаще, чем сейчас.

Серверные компоненты — React выходит на сервер

Ещё одна революционная идея команды React — React Server Components (RSC), или серверные компоненты. Это попытка объединить лучшее из мира серверного рендеринга и клиентских SPA. Смысл в том, что если часть ваших React-компонентов может выполняться только на сервере, генерируя готовый HTML, который отправляется клиенту, то пусть они и исполняются на сервере, не загружая клиент. Эти компоненты никогда не попадают в бандл JS, не несут в себе интерактива — они чисто для рендеринга контента. Другая часть компонентов всё также остаётся клиентской, это давно знакомые нам React-компоненты, которые умеют обрабатывать события, имеют какое-то своё состояние и т.д. Разделение происходит явно: React различает, какой компонент предназначен для сервера, а какой — для клиента.

Как же React понимает, в какой среде выполнять код компонента? Введена директива "use client": если файл компонента начинается с этой строки, то компонент клиентский, он будет собран в JS и выполнится в браузере. Если же такой строчки нет — компонент считается серверным и по умолчанию выполнится на сервере (например, при рендеринге страницы на Node.js). Серверный компонент может содержать асинхронный код (запросы к БД, файловой системе и т.п.), ведь он запускается в среде сервера. Но он не может использовать, например, useState или useEffect, ведь у него нет постоянного состояния между запросами, да и доступ к DOM он не имеет.

React 18 (и в полной мере React 19) позволяет фреймворкам использовать эту возможность. Например, Next.js 13 с новым app/ роутером делает все компоненты по умолчанию серверными, если не указать "use client". Таким образом, большую часть страницы вы можете рендерить на сервере, отдавая сразу на клиент сразу готовую разметку, а для интерактивных элементов использовать клиентские компоненты.

Преимущества Server Components:

• Производительность. Серверные компоненты избегают гидрации, клиенту не нужно повторно исполнять JS, чтобы восстановить состояние UI. Вы получаете выгоды SSR (быстрый первый рендер, минимум работы на клиенте) без обычных недостатков SSR (необходимость гидрации большого объёма HTML).
• Безопасность. Чувствительный код остается на сервере, не попадает в бандл, и данные можно получать напрямую на сервере (например, напрямую из базы) без передачи ключей API в браузере.
• Размер бандла существенно сокращается, ведь клиент вообще не получает код серверных компонентов, только итоговую HTML разметку и нужный JS для оставшихся клиентских компонентов.

Как это выглядит на практике? Самый понятный пример:

Представим блог. Страницу поста можно сделать целиком серверным компонентом, на сервере загрузится пост из БД и вернёт нам готовую верстку статьи. А вот кнопка лайка или форма добавления комментария — это уже интерактив, их делаем клиентскими компонентами. В результате пользователь, заходя на страницу, сразу же получит полностью готовую страницу поста (никакого лоадера, всё пререндерено). А JS-код загрузится для кнопки лайка и формы комментария, и только они будут гидрироваться и начнут работать на клиенте. Это сочетание SSR и SPA, orchestrated by React.

React строго определяет, как серверные и клиентские компоненты могут взаимодействовать. Серверный компонент может импортировать и использовать другой серверный или клиентский компонент, а вот клиентский компонент не может импортировать серверный. То есть дерево может быть: Серверный → внутри него Клиентский → внутри него ещё Клиентский и т.д. Но не наоборот. В примере выше серверный компонент страницы может рендерить внутри себя <LikeButton /> (клиентский компонент кнопки). А если бы вы попробовали внутри клиентского компонента сделать import PostDetails from './PostDetails.server.jsx' — сборка не позволит, скажет, что так нельзя. Таким образом, архитектура разделяется: «верхние» уровни страницы — серверные, «листья» интерактивности — клиентские.

Server Components — пока прерогатива фреймворков. То есть в обычном приложении вы не сможете воспользоваться этим вручную без большого труда. Но если вы работаете с Next.js, Remix или в целом с fullstack React-приложениями, то RSC уже доступны. В React 19 они обещают быть полностью стабильными (в React 18 это скорее эксперимент для энтузиастов). Библиотеки тоже начинают подстраиваться: например, React Router v7 планирует поддерживать RSC, Vite тоже экспериментирует с этим.

Что в итоге нам дают серверные компоненты? Потенциально — большой скачок в производительности и удобстве разработки fullstack приложений. Мы получаем паттерн разделения по среде: какие компоненты должны рендериться на сервере, а какие — на клиенте. Это новое измерение при проектировании React приложения. Разработчику теперь нужно будет думать не только о разделении логики и UI, или о переиспользовании кода, но и решать, где лучше его выполнить — на сервере или в браузере. Правильное использование RSC может значительно ускорить приложение без лишних усилий для разработчика (React сам решит, когда и что подгружать, синхронизирует состояние между сервером и клиентом).

С другой стороны, появляется дополнительная сложность в понимании: нужно чётко осознавать ограничения (например, нельзя в серверном компоненте использовать useEffect, или что состояние в серверном компоненте не сохраняется между запросами). Но это всё решается практикой и хорошей документацией.

Заключение

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

• Container & Presentational Components привносят порядок, отделяя логику от отображения.
• HOC и Render Props — старые приёмы для переиспользования кода, которые в значительной мере вытеснены более современными хуками, но по прежнему встречаются в проектах.
• Compound Components демонстрируют силу композиции, предоставляя API для гибкой сборки компонентов из небольших частей.
• А Suspense и Server Components — это уже ближайшее будущее, делающее работу с асинхронностью и рендерингом более эффективной и декларативной.

Важно понимать, что паттерны — это не нерушимые догмы. В каждом конкретном случае их нужно применять с умом. Порой проще обойтись без паттерна, чем усложнять архитектуру ради «красивого» решения. Не нужно лишний раз оверинженирить. Однако знание этих подходов обогащает ваш инструментарий. Когда вы сталкиваетесь с определённой проблемой, на подкорке всплывёт: «ага, здесь бы подошёл такой-то паттерн!» Опытный разработчик видит несколько вариантов реализации и выбирает оптимальный.

От себя добавлю: изучая паттерны, всегда пробуйте их в деле. Напишите свой HOC, переделайте компонент с Render Props на хук, реализуйте небольшой набор Compound Components — так вы прочувствуете их сильные и слабые стороны. React развивается, и появляются новые приёмы, но фундаментальные идеи (композиция, разделение обязанностей, явное управление состоянием) остаются. Владейте этими инструментами, и ваши React приложения будут благодарить вас чистотой и поддерживаемостью кода!

Паттерны в React нужно не только знать, но и применять. Собрали полезные инструменты здесь.

Что вообще такое context collapse

Есть вероятность, что вы слышите этот термин в первый раз. Немного лирики: в мире микросервисов есть два понятия: технический контекст и доменный контекст (Bounded Context).

Технический контекст

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

Без технического контекста микросервисы не могут:

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

Доменный контекст (Bounded Context)

Доменный контекст происходит из методологии Domain-Driven Design (DDD) — это про четкое разделение бизнес-логики между микросервисами. У каждого сервиса должна быть своя «ограниченная область» (Bounded Context), где термины, данные и правила имеют уникальное значение.

Например, в интернет-магазине слово «заказ» может означать разные вещи для сервиса оплаты (финансовая транзакция) и сервиса доставки (отправка покупателю). Если границы контекста не определены четко, возникает путаница: сервисы начинают дублировать логику или интерпретировать данные по-разному.

Без доменного контекста:

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

Вернемся к коллапсу контекста

Автор статьи просит нас представить следующую картину: вы сделали новую архитектуру, она масштабируется, разделяется, деплои проходят гладко, CI/CD пайплайны цветут и пахнут — другими словами, не архитектура, а мечта. Все работает как часы, поэтому вы сидите, попивая кофе и раскладывая пасьянс.

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

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

Что на самом деле происходит

Представьте, что микросервисы — это эстафетный забег: каждый сервис передает «эстафетную палочку» — идентификаторы пользователей, сессионные данные, намерения — следующему участнику. Контекстный коллапс случается, когда эта палочка выпадает на бегу.

Сервис теряет важное состояние, например:

• «Это корзина Пети»
• "Этот платеж уже прошел"

И начинается хаос: дублирующиеся API-запросы, потерянные транзакции или, что еще хуже, повреждение данных.

В 2025 году появляется все больше слишком фрагментированных архитектур и гипермасштабируемых систем. Ваши запросы могут проходить через 10, 20 и даже 30 сервисов, но если на каком-то этапе отвалился контекст, то это конец.

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

Как понять, что контекст вот-вот может «коллапснуться»

Вы наверняка были в такой ситуации: вы на 100% уверены, что система должна работать, но она не работает, хотя ошибок в коде никаких, казалось бы, нет. Вот основные признаки коллапса, с которыми вы можете столкнуться:

• Всплеск пинга: сервисы запрашивают данные, которые должны бы уже знать, создавая огромное количество лишних вызовов и перегружая API.
• Дублирующиеся действия: повторные списания, задвоенные отправки писем, неожиданные повторные заказы. Пользователи возмущены, рейтинг падает.
• Мистические баги: логи говорят «всё в порядке», но результат явно неверный. Код не видит проблему, а отладка превращается в кошмар.

Давайте рассмотрим на примере. Клиент решает перевести деньги с одного счёта на другой. Сервис транзакций отправляет запрос в модуль проверки лимитов, затем передаёт его в систему обработки платежей. Но из-за потери контекста на одном из этапов модуль проверки лимитов теряет информацию о сессии клиента и воспринимает его как нового пользователя. В результате:

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

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

Опрос CNCF за 2024 год показал, что 68% команд, которые используют микросервисы, сталкиваются с необъяснимыми проблемами производительности. И всему виной в том числе контекстный коллапс.

5 решений, как бороться с контекстным коллапсом

Да, контекстный коллапс — крайне неприятный баг. Главное — чтобы все сервисы работали слаженно и «знали» друг друга.

1. Правильно передавайте контекст

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

Вот пример реализации middleware автором на Go:

2. Кэшируйте с умом

Нет смысла заставлять сервисы угадывать, если они просто могут запомнить. Быстрый кэш, например, с Redis, может хранить временный контекст — например, токены сеанса или состояния запросов, — поэтому сервисы не будут постоянно спрашивать «кто это?» Вот фрагмент кода на Питоне, где используется Redis для хранения и извлечения контекста:

Это позволяет поддерживать контекст во всех вызовах, не перегружая вашу базу данных. А еще TTL (time-to-live) Redis сам за собой убирает — устаревшие данные не скрываются.

3. Используйте Event-Driven Architecture

Микросервисы без сохранения состояния выглядят отлично, пока не контекст не коллапснется. Событийная архитектура идет от обратного: вместо того чтобы надеяться, что службы все запомнят, регистрируйте каждый шаг как событие. Если служба все-таки забудет, воспроизведите поток. Вот пример на Node.js с Kafka:

Здесь также можно использовать RabbitMQ. В общем, больше никаких отговорок со стороны сервиса из разряда «я забыл».

4. Проверяйте логи

Когда контекст теряется, логи — ваше место преступления. Настройте Grafana Loki или Datadog для поиска «потерянных контекстов». Вот пример с Grafana:

Тэгните логи с помощью request_id или user_id, а затем вызовите Loki:

5. Тестируйте на коллапсы

Профилактика лучше, чем лечение. Добавьте хаос-тестирование с помощью, например, Chaos Mesh, чтобы моделировать потери контекста.

Хаос-тестирование — это метод преднамеренного введения сбоев в систему, чтобы проверить, насколько она устойчива и надежна. Обычное тестирование и мониторинг могут выявить проблемы, но хаос-тестирование (Chaos Engineering) помогает увидеть, как система поведет себя в случае неожиданных отказов.

Прервите mid-requests к сервисам — сможет ли система восстановится в таком случае? Если нет, значит, ваша передача контекста недостаточно надежна.

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

Новость быстро разлетелась по сообществам, но на деле всё не так однозначно, пишет разработчик Оскар Дудич в рамках Architecture Weekly.

Речь идёт о скорости компиляции, а не исполнения кода. Ваши приложения не станут работать быстрее — только собираться. Это как если бы производитель автомобилей сказал, что «машина стала в 10 раз быстрее», а потом уточнил, что речь о производстве, а не скорости на трассе.

Почему решили переписать и причём тут Go

Компилятор — это CPU-bound задача. Он не ждёт ответа от базы данных и не занимается сетевыми запросами. Он грузит процессор на полную, разбирая дерево типов, анализируя код и генерируя выходной файл.

Node.js с его однопоточной моделью и event loop плохо подходит для таких задач. Он отлично работает в веб-серверах — там важна скорость отклика и работа с I/O, но не тяжёлые вычисления. Компилятор TypeScript вырос, стал сложнее, и старая архитектура начала тормозить.

Go здесь оказался подходящим выбором:

• у него есть легковесные потоки (goroutines);
• параллельное выполнение встроено на уровне языка;
• нет нужды в трюках с worker threads, как в Node.js;
• проще работать с памятью и сложными структурами.

Почему просто не использовать worker threads в Node.js?

Это возможно, и они действительно дают параллельность. Но:

• переписывать старый код с учётом многопоточности — больно;
• обмен данными между потоками в Node.js идёт через сериализацию;
• каждый поток создаёт свой V8-инстанс, что дорого по ресурсам.

Команда решила не латать старое, а начать с чистого листа. И, как показали первые тесты, даже однопоточный Go-компилятор оказался быстрее, чем старый на Node.js.

А что с браузерами и плагинами?

Это пока не ясно. В браузерах Go не работает нативно, и придётся либо компилировать его в WebAssembly, либо сохранить JS-версию для playground'ов. Вопросов больше, чем ответов:

• как сохранить совместимость с TypeScript-плагинами;
• будет ли 100% повторяемость в поведении компилятора;
• изменятся ли ошибки, предупреждения и тонкости типов.

Зачем вообще об этом думать

Это кейс о масштабировании и выборе инструментов. То, что хорошо работало в 2012 году, перестаёт тянуть в 2025-м. Переписывание проекта — не всегда трагедия. Иногда это необходимость, если фундамент начал мешать росту.

Важно не повестись на «10x быстрее». Такие цифры всегда требуют контекста. Но и отрицать ценность изменений не стоит — особенно если вы работаете с большими кодовыми базами и каждый процент ускорения важен.

Почему это вообще важно?

AI-инструменты уже не просто помогают разработчикам — они активно пишут код. GitHub Copilot, ChatGPT, Codeium и другие способны за секунды сгенерировать сложные алгоритмы, SQL-запросы, тесты и даже целые API. С одной стороны, это удобный способ ускорить разработку, снизить рутину и сделать код чище. Но с другой — AI-код не всегда надежен, а слепое копирование может привести к багам и уязвимостям.

Если раньше единственной угрозой было «гуглить решения на Stack Overflow», то теперь ситуация сложнее: AI-код может быть логически неверным, не соответствовать бизнес-требованиям или использовать устаревшие практики. При этом его сложно сразу раскритиковать — он выглядит идеально, четко структурирован и, на первый взгляд, работает.

Собрали основные причины, почему важно уметь отличать AI-код от написанного человеком:

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

Кроме того, AI-код всё чаще встречается не только в продакшн-решениях, но и на собеседованиях. Работодатели начали сталкиваться с кандидатами, которые просто копируют ответы из ChatGPT и не могут объяснить, как работает их код.

По данным Stack Overflow Developer Survey 2024, более 70% разработчиков уже используют AI в кодинге, а 40% признались, что нейросети хоть раз предлагали им потенциально небезопасные решения. Поэтому сейчас важно не просто уметь пользоваться AI, но и понимать, где он может навредить.

Где чаще всего встречается AI-код?

AI-сгенерированный код может появиться где угодно: от свежего pull request’а в репозитории до ответа на Stack Overflow или тестового задания кандидата. Иногда это просто вспомогательные сниппеты, а иногда — полноценные фрагменты, которые выглядят слишком «чисто», но вызывают ощущение, что что-то не так.

Разберем, в каких ситуациях чаще всего встречается AI-код и как его распознать.

Кодовые ревью

Допустим, в репозиторий приходит pull request, и он выглядит… странно. Формально код работает, но:

• Он слишком абстрактный и не учитывает специфику проекта.
• Переменные и методы названы шаблонно: processData(), getResponse(), handleRequest().
• Комментарии избыточны или выглядят так, будто их писал учебник: «Этот метод сортирует массив по возрастанию» (да, спасибо, КЭП).
• Код слишком формальный, без характерных для команды решений или оптимизаций.

Пример:

Вы просите разработчика написать логику валидации email-адреса, а в PR прилетает нечто такое:

Формально всё корректно. Но если в вашем проекте уже есть встроенные механизмы валидации (например, DataAnnotations в .NET), такой код выглядит излишним. Кроме того, регулярка взята из учебников и не учитывает edge-кейсы. Это может быть явным признаком AI-генерации.

Форумы и Stack Overflow: кто-то выкладывает красивый, но подозрительно академичный код

AI-код часто появляется в ответах на Stack Overflow, GitHub Discussions или Reddit. На первый взгляд, он идеален, но:

• Не учитывает контекст задачи;
• Не использует упрощения, принятые в реальной разработке;
• Выглядит так, словно его писал преподаватель для учебного пособия.

Пример:

Кто-то спрашивает: «Как перевернуть строку в Python?»

Ответ от AI:

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

Или

Люди обычно пишут проще и без ненужных комментариев.

AI-код в legacy-проектах: «быстро сгенерили, а потом никто не разобрался»

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

Пример:

Вы находите в коде функцию, которая вроде бы что-то делает, но написана так, что ее никто не понимает:

Комментариев нет, названия переменных обобщенные. Оказывается, это было быстрое AI-решение для шифрования, но никто не знал, что тут XOR с чередующимися ключами.

Еще один тревожный сигнал — фрагменты кода, которые выглядят слишком универсально, но плохо вписываются в логику проекта. Например, в коде на C# встречается сложная реализация сортировки, хотя в .NET уже есть встроенные методы, делающие то же самое.

Интервью и тестовые задания: как отличить, решал ли кандидат сам или просто скормил задачу нейросети?

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

Как распознать AI-код на интервью:

• Кандидат использует нестандартные или слишком формальные конструкции, которые редко встречаются в индустрии;
• В коде много избыточных комментариев, будто их писал учебник;
• Кандидат не может объяснить, почему использовал именно это решение;
• В коде встречаются устаревшие или малоиспользуемые подходы.

Пример:

Вы даете тестовую задачу: «Напишите функцию для поиска всех простых чисел до N».

AI-кандидат приносит это:

Формально всё правильно, но человек, скорее всего, объяснил бы решение проще и без таких заумных комментариев.

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

Шпаргалка: 6 признаков, что код написан AI

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

Слишком академичный стиль

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

Пример:

Кто-то просит написать функцию на Python для поиска максимального значения в списке. Человек бы написал так:

AI же может предложить развернутый вариант:

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

Избыточные и очевидные комментарии

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

Пример:

Разработчики так не пишут — слишком очевидные комментарии просто мешают читать код.

Неестественные или шаблонные названия переменных

AI генерирует код по шаблону и часто использует слишком общие, но «правильные» названия.

Пример:

В реальности разработчик скорее назвал бы класс CsvParser или LogAnalyzer, а не абстрактный DataProcessor.

Неоптимизированные решения, игнорирующие стандартные библиотеки

AI может создать велосипед, даже если есть готовое стандартное решение.

Пример:

Запрос: «Написать код, который объединяет строки в список с запятыми».

AI-код:

Но в Python есть встроенный join(), и нормальный разработчик написал бы просто:

Код слишком универсален, но не учитывает реальный контекст

AI пытается писать универсальные решения, даже если это не нужно.

Пример:

Допустим, нужна функция, которая складывает два числа. Человек просто сделает:

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

На вид хорошо, но зачем здесь проверка на отрицательные числа?

Используются устаревшие или редко применяемые методы

AI может выдавать код, который выглядит нормально, но использует уже неактуальные или малоиспользуемые подходы.

Пример:

Для чтения файлов в Python AI может предложить:

Хотя уже давно правильный вариант:

Так код выглядит безопаснее и не оставляет открытые файловые дескрипторы.

Хотя AI часто можно вычислить, это не значит, что его нельзя применять. Наоборот, в ряде случаев нейросети могут здорово ускорить работу разработчиков. Главное — понимать, где AI будет полезным помощником, а где может навредить. Рассмотрим несколько сценариев, в которых сгенерированный код действительно помогает.

AI-код не всегда плох: когда его можно (и нужно) использовать

Генерация шаблонного кода (CRUD-операции, конфигурации, тесты)

Разработчики часто сталкиваются с задачами, которые повторяются от проекта к проекту. Например, создать REST API с базовыми CRUD-операциями, написать конфигурационные файлы или сгенерировать unit-тесты.

Пример:

Допустим, нужно быстро создать контроллер для работы с сущностью User в Node.js + Express. Человек может вручную писать стандартные GET, POST, PUT и DELETE, а может поручить это AI:

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

Когда стоит использовать?

• Генерация стандартных CRUD-операций;
• Создание базовых конфигурационных файлов (например, docker-compose.yml);
• Автоматическое написание тестов для базовых сценариев.

Автоматизация рутинных задач (генерация SQL-запросов, скрипты для CI/CD)

AI отлично справляется с рутинными задачами, которые требуют знаний синтаксиса, но не требуют креативности. Например, он может быстро сгенерировать сложный SQL-запрос или YAML-скрипт для CI/CD.

Пример:

Нужно составить SQL-запрос для получения списка клиентов, которые сделали заказ в последние 30 дней. AI может сразу предложить готовое решение:

Вручную писать такие запросы несложно, но если их много, AI может сэкономить кучу времени.

Когда стоит использовать?

• Написание SQL-запросов на основе простых описаний;
• Генерация конфигураций CI/CD (например, .gitlab-ci.yml или Jenkinsfile);
• Создание вспомогательных скриптов для автоматизации (например, bash-скриптов для деплоя).

Помощь в написании boilerplate-кода и документации

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

Пример:

AI может быстро создать интерфейс для TypeScript на основе JSON-данных. Так:

AI-сгенерированный TypeScript-интерфейс:

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

Когда стоит использовать?

• Написание интерфейсов и типов для TypeScript или Java;
• Генерация обработчиков исключений и логирования;
• Автоматическое создание документации (например, для API в OpenAPI/Swagger).

Генерация идей, но не слепое копирование (AI как ассистент, а не разработчик)

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

Пример:

Разработчик хочет ускорить поиск в огромном массиве данных. AI предложит несколько алгоритмов (B-дерево, бинарный поиск, хеш-таблицы), а уже сам программист выберет, что подходит лучше.

Когда стоит использовать?

• Когда нужна структурированная подборка идей.
• При изучении новых технологий — AI может быстро объяснить базовые принципы.
• При генерации альтернативных решений, чтобы оценить их плюсы и минусы.

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

Как научиться быстро определять AI-код?

Понимание того, что перед вами код, сгенерированный AI, — не просто навык, а важная часть профессиональной гигиены разработчика. Поэтому важно научиться быстро отличать машинный код от человеческого. Разберем несколько стратегий.

Задавайте себе правильные вопросы

Когда видите код (в PR, на форуме, в тестовом задании), попробуйте мысленно пройтись по этим вопросам:

• Логична ли структура? Если код выглядит идеально отформатированным, но при этом содержит нелогичные или избыточные конструкции, это подозрительно.
• Есть ли повторения? AI любит дублировать куски кода, даже если их можно оптимизировать.
• Реализация слишком академичная? Если код выглядит так, будто его писал профессор компьютерных наук, но без учета реального использования — возможно, его сгенерировал AI.
• Код соответствует задаче или просто «выглядит умно»? Иногда AI генерирует код, который слишком сложен для простой задачи. Например, вместо for-цикла он может предложить рекурсивный алгоритм без реальной необходимости.

Сравнивайте с примерами из реального продакшен-кода

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

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

Проверяйте код на избыточность и неестественные конструкции

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

• Ненужные проверки (if True:);
• Лишние константы вместо прямых значений;
  
• Чрезмерная типизация в языках, где это необязательно;
  
• Странные циклы, когда можно использовать встроенные методы.

Определять AI-код — навык, который развивается с опытом. Главное — обращать внимание на логику, осмысленность и соответствие реальным сценариям использования. Если код кажется слишком правильным, но при этом странным — скорее всего, его написал не человек.

Как это реализуется на практике? Есть несколько способов работы с информацией. Наиболее востребованные из них — это cookies, localStorage и sessionStorage. Эти инструменты отличаются друг от друга, но далеко не все разработчики могут объяснить разницу между ними.

Узнаем, что собой представляют cookies, localStorage и sessionStorage, каковы их основные характеристики и особенности, как они применяются и какой способ работы с данными лучше.

Cookies

На заре интернета cookies были безальтернативным вариантом хранения данных на стороне клиента. Файлы куки представляют собой элементарные пары типа «ключ-значение» и используются для:

• управления текущими сессиями;
• персонализации пользователя;
• отслеживания его активности.

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

По сути куки — это ограниченные по размеру текстовые файлы, которые сайт сохраняет на устройстве пользователя. Объем данных в «печеньках» лимитирован — это не больше 4 КБ, при этом у них есть срок хранения, который устанавливает разработчик ресурса.

Например, в Google есть файлы аналитики для сбора информации, которые хранятся от 6 до 24 месяцев. Некоторые cookies действуют только в период работы в браузере и при закрытии автоматически уничтожаются, другие хранятся в течение всего перерыва между сессиями — их срок жизни зависит от выполняемых задач.

Куки почти идеальный инструмент для идентификации посетителя, но сам пользователь может отключить их почти на любом ресурсе, что делает «печеньки» недостаточно надежным хранилищем информации.

Развитие этого инструмента продолжается. Например, в экосистеме Chromium доступна версия, которая поддерживает общую память и асинхронный API CookieStore — им можно пользоваться без блокировки главного потока.

Закрепим основные характеристики cookies:

• сохраняют данные, которые передаются на сервер с помощью заголовков;
• локальные и сессионные куки-хранилища существуют только на стороне клиента;
• сроки хранения устанавливаются заранее при создании куков;
• объем ограничен (4 КБ);
• бывают защищенные куки, но в этом случае их содержимое будет недоступным на клиентской стороне — такой формат используется для аутентификации пользователей при хранении их токенов.

Способ хранения данных в cookies имеет определенные ограничения. Чтобы сохранить корректность запроса, содержимое должно быть закодированным и безопасным. При этом интерфейс для чтения и записи cookies не всегда удобный, что вынуждает разработчиков работать с ним не напрямую, а через сторонние библиотеки.

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

Разработчики на JavaScript используют свойство document.cookie, которое предоставляет строковый формат для работы всех cookies, связанных с текущим процессом. Пример кода:

В этом примере для установки cookie разработчик присваивает строку свойству document.cookie. Можно задать дополнительные свойства — например, срок действия, путь или домен.

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

Разработчики устанавливают и читают cookie через заголовки Set-Cookie и Cookie непосредственно в протоколе HTTP. В приложениях куки устанавливают и считывают с помощью соответствующего API либо модуля файлов cookie на одном из серверных языков — например, Node.js.

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

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

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

LocalStorage

Это более продвинутый формат хранилища в браузере, позволяющий сайтам сохранять больше информации без ущерба для трафика. LocalStorage создали в качестве альтернативы cookie, чтобы обойти ограничения последних. А именно — небольшой объем хранилища, необходимость постоянно передавать данные с сервера в браузер и обратно. В localStorage работа с данными стала проще и эффективнее.

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

Информация хранится в формате «ключ-значение» в виде строк. Даже если ввести числовые или логические данные, они преобразуются в строчные. Для использования хранилища в JavaScript используют объект localStorage.

Пример кода:

Запись напоминает код для сеансового хранилища. Метод setItem() используется для хранения данных, метод getItem() — для их получения, removeItem() — для удаления конкретных элементов, clear() — для полной очистки данных. Несмотря на то, что в localStorage сохраняются только строки, с помощью JSON разработчики могут взаимодействовать и с более сложными типами данных.

Основные характеристики localStorage:

• данные хранятся бессрочно;
• очистить хранилище можно только принудительно — через код JavaScript или полную очистку браузерного кэша пользователем;
• объем данных для хранения — 5-10 МБ (по этому показателю localStorage лидирует среди всех хранилищ);
• старыми браузерами не поддерживается — например, на IE7 это локальный ящик не работает;
• действует по принципу ограничения домена — сохраненная информация доступна лишь одному источнику.

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

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

SessionStorage

Способ работы с данными sessionStorage во многом аналогичен localStorage, но есть принципиальное отличие — после закрытия браузера данные полностью удаляются. Это не означает, что sessionStorage — хуже, просто у него другая сфера применения. В частности формат идеален для хранения данных, актуальных в рамках конкретной сессии — например, информации при заполнении формы или вводе данных банковской карты.

Объем хранилища ограничен, но в большинстве случаев этого достаточно для хранения инфы в пределах одного сеанса. Данные по сути не защищены, так что вопрос приватности — забота пользователя.

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

Для подключения сеансового хранилища разработчики на JavaScript используют объект sessionStorage и методы для получения, установки и удаления данных.

Пример кода:

Как видите, есть определенное сходство с localStorage, поскольку у хранилищ одинаковый алгоритм работы. Метод setItem() применяется для сохранения данных (первый аргумент — ключ, второй — значение), метод получения — removeItem(), для очистки используется метод clear().

Основные характеристики sessionStorage:

• данные хранятся в течение одной сессии, после закрытия браузера очищаются;
• хранилище использует контекст браузера верхнего уровня, то есть в каждой вкладке содержатся уникальные данные;
• объем данных — 5 МБ;
• старые браузеры формат не поддерживают.

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

Способ SessionStorage применяют для сохранения данных неавторизованных посетителей в онлайн-магазинах — какие товары он смотрел, какие положил в корзину. Формат используется также в случаях, когда применение localStorage нецелесообразно — например, при заказе еды в ресторанах. В локальном хранилище посетитель бы увидел прошлый заказ, который он собирал и не оформил, но меню к тому времени может поменяться. В сессионном хранилище актуальный заказ будет собран по новой.

Сравнение cookies, localStorage и sessionStorage

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

Размер хранилища

• Файлы cookie. Здесь размер минимальный. Для каждого домена куки могут хранить ограниченный объем данных — как правило, не больше 4 КБ.
• LocalStorage. Максимально возможный объем данных для каждого домена — не менее 5 МБ, а при использовании определенных настроек и больше.
• SessionStorage. Здесь хранится больше данных для одного домена в сравнении с cookies. Размер — не более 5 МБ.

Срок хранения

• Файлы cookie. Данные куки могут быть сеансовыми или постоянными в зависимости от настроек. Постоянные имеют свой срок действия, который исчисляется месяцами или даже годами, сеансовые уничтожаются сразу после завершения сеанса.
• LocalStorage. Данные в локальном хранилище остаются после закрытия браузера и его повторного открытия. Удалить их может только пользователь или код JavaScript.
• SessionStorage. Информация в сеансовом хранилище остается, пока открыта вкладка сайта. При закрытии данные удаляются.

Работа с данными

• Файлы cookie. Разработчик может установить срок действия для файлов, после которого браузер автоматически очистит куки.
• LocalStorage. Нельзя запрограммировать автоматическое удаление данных или другие действия с ними. Они сохраняются, пока не будут удалены принудительно.
• SessionStorage. Здесь нет механизма автоматического истечения срока действия. Поэтому данные будут актуальны, пока открыта страница.

Доступ к данным

• Cookies. Доступ к файлам можно получить и изменить через JavaScript API, но существуют определенные ограничения для третьих лиц.
• LocalStorage и sessionStorage. Есть прямой доступ к информации в хранилищах через API JavaScript, который позволяет манипулировать данными.

Сетевой трафик

• Cookies. Данные автоматически отправляются на север после каждого HTTP-запроса для соответствующего домена, что увеличивает загрузку трафика.
• LocalStorage и sessionStorage. Данные не отправляются на сервер, а остаются на стороне клиента, что сокращает объем лишнего трафика.

Когда использовать cookies, localStorage и sessionStorage

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

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

Разницу в жизненном цикле cookies, localStorage и sessionStorage используют в соответствии с задачами хранения. Ограниченный срок действия cookies и данных сессионного хранилища могут стать преимуществами в одном случае и недостатками в другом. С данными localStorage аналогичная ситуация — если нужен полный контроль времени хранения, этот формат идеально подходит.

Проблемы и перспективы хранилищ данных

Все хранилища потенциально уязвимы для XSS-атак. В cookies применяют дополнительные меры защиты: флаги HTTPOnly и Secure запрещают доступ из JavaScript к файлам, чувствительным к безопасности. Для отправки таких файлов используется передача по шифрованным каналам HTTPS.

Для защиты от атак CSRF (подделка межсайтовых запросов) используют атрибут SameSite, проверку HTTP_Referer/Origin или применение синхронизированных токенов.

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

Учитывайте, что куки могут замедлять загрузку, особенно если у пользователей низкая скорость интернета. LocalStorage на HTTP-запросы не влияет, что положительно отражается на производительности веб-ресурса.

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

Что такое облачные IDE и почему они важны

Облачные IDE (или онлайн-редакторы кода) позволяют работать над проектом прямо из браузера, без сложной локальной настройки окружения. На сервере уже установлены необходимые инструменты (компиляторы, интерпретаторы), можно быстро переключаться между различными стеками технологий. Это удобно, когда нужно:

1. Быстро протестировать идею или прототип,
2. Работать из любого места и с любого устройства,
3. Обучаться программированию (особенно новичкам, которым сложно настраивать среду разработки),
4. Совместно редактировать код в реальном времени.

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

Replit

Replit был одним из первых облачных решений, с которыми я столкнулся. Он ориентирован на скорость старта: заходишь на сайт, создаёшь «репл» (так называются проекты в Replit), выбираешь язык — и готово. Уже предустановлен интерпретатор или компилятор, можно писать и сразу же запускать программу.

Возможности

• Поддержка множества языков: Python, JavaScript, C++, Java, Go, Rust и другие.
• Встроенный чат с искусственным интеллектом (Ghostwriter) для помощи в написании кода.
• Возможность совместной работы: можно дать ссылку коллеге, и он зайдёт в ваш проект, чтобы вместе отлаживать или рефакторить код.
• Хостинг: Replit умеет публиковать веб-приложения «на живом URL» одним нажатием кнопки.

Плюсы

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

Минусы

• Не всегда удобен для серьёзных проектов: базовые настройки окружения ограничены, а для расширенных сценариев нужен платный тариф.
• Интерфейс может работать медленнее, если проект становится большим или инсталляция зависимостей тяжёлая.

Где пригодится

• Отличный вариант для новичков, которые хотят учиться программировать без сложной настройки локальной среды.
• Быстрые прототипы, демонстрации кода на собеседованиях или парное программирование.

CodeSandbox

CodeSandbox ориентирован, прежде всего, на фронтенд-разработчиков. Он замечательно подходит для проектов на React, Vue, Angular, Svelte и других библиотечных и фреймворковых решениях.

Возможности

• Автоматическое создание окружения для фронтенд-проектов: нужен React? Выбираем шаблон — и сразу получаем структуру, файлы конфигурации и пакетный менеджер.
• «Live preview» (живая перезагрузка): при каждом изменении в коде страница в правой части обновляется без перезагрузки.
• Интеграция с GitHub: можно подтянуть репозиторий, внести правки в CodeSandbox, а затем запушить изменения обратно.
• Возможность запускать бэкенд-сервер (через Docker-контейнеры) в отдельных sandboxes.

Плюсы

• Удобно для веб-разработки: всё уже настроено (Webpack, Vite или другие сборщики).
• Поддержка TypeScript из коробки.
• Отлично работает совместное редактирование, есть возможность прямого «шеринга» результатов.

Минусы

• Фокус именно на веб-технологиях, так что для языков, не связанных с фронтендом, CodeSandbox не всегда подойдёт.
• Бесплатные sandboxes могут засыпать при простое, что не всегда удобно для постоянного хостинга.

Где пригодится

• Быстрые демки UI-компонентов или обучающие примеры для фронтенда.
• Когда нужно показать коллегам, как работает тот или иной React-хук, без установки Node.js локально.
• Создание небольшого прототипа веб-приложения в режиме реального времени.

GitHub Codespaces

GitHub Codespaces — по сути, облачное продолжение Visual Studio Code. Если у вас есть репозиторий на GitHub, вы можете открыть его в Codespaces и получить преднастроенную среду разработки прямо в браузере. Это решение особенно нравится разработчикам, которые уже привыкли к VS Code.

Возможности

• Полноценная интеграция с GitHub: открываем репозиторий, создаём Codespace, и всё готово к работе.
• Расширения VS Code в облаке: многие привычные плагины можно установить и использовать.
• Поддержка Docker и Dev Containers: можно создавать контейнеры со своим набором инструментов, чтобы каждый член команды имел идентичную среду.
• Возможность «подцепиться» к Codespaces и локальным VS Code, если хочется работать в офлайне или со своим привычным окружением.

Плюсы

• Знакомая среда для тех, кто пользуется VS Code.
• Гибкий вариант конфигурации (Dev Containers), позволяющий упростить онбординг новых сотрудников.
• Нет проблем с зависимостями: всё хранится в контейнере, поэтому переходить между проектами очень удобно.

Минусы

• Требует платного тарифного плана GitHub, если нужен серьёзный объём ресурсов (хотя есть ограниченное бесплатное время).
• Для маленьких проектов может быть избыточен, так как мощь Codespaces раскрывается больше в средних и крупных командах.

Где пригодится

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

JetBrains Fleet

Fleet — новый проект от JetBrains, который позиционируется как «умная и быстрая» IDE нового поколения. Предлагается как облачная среда с возможностью локальной установки. JetBrains известны своими тяжёловесными, но очень функциональными IDE (IDEA, PyCharm, WebStorm и т.д.), а Fleet стремится занять более лёгкую нишу с возможностью работать в облаке.

Возможности

• Режим «смарт-редактирования», когда Fleet по мере необходимости подгружает функции анализа кода.
• Распределённая архитектура: можно разворачивать часть Fleet в локальном окружении, часть — в удалённом, чтобы снизить нагрузку на машину.
• Совместное редактирование кода в реальном времени, причём JetBrains обещают, что это будет «ровно, как в Google Docs, только для кода».

Плюсы

• Потенциально более лёгкая, чем классические JetBrains IDE, работает быстрее на слабом железе.
• Глубокий анализ кода, как и во всех решениях JetBrains, что особенно полезно для больших проектов.

Минусы

• Fleet пока ещё развивается, некоторые функции отсутствуют или реализованы не до конца.
• Менее дружелюбен к новичкам, чем Replit или CodeSandbox, потому что ориентирован скорее на опытных разработчиков.

Где пригодится

• Разработка на языках, где особенно важны рефакторинг и интеллектуальные подсказки: Java, Kotlin, Python и т.д.
• Если нужна более «лёгкая» альтернатива классическим IDE JetBrains, но при этом с возможностью работать удалённо.

StackBlitz

StackBlitz — ещё один «фронтенд-ориентированный» онлайн-редактор, но с упором на выполнение кода прямо в браузере без специальных серверных окружений. Он запускает Node.js-среду в браузере через WebAssembly, благодаря чему проекты могут работать очень быстро и автономно.

Возможности

• Мгновенный запуск Angular, React, Vue, Svelte и т.д., без серверной компоненты.
• Поддержка Node.js-приложений (через WebContainers) прямо в браузере: по сути, локальная VM работает «внутри» вкладки.
• Отличная интеграция с GitHub и возможность деплоя проектов.

Плюсы

• Реально быстрая загрузка и мгновенный старт проектов на популярных фреймворках.
• Почти не зависит от «серверной» стороны, потому что всё работает через WebContainers.
• Хорошо подходит для офлайн-режима (в разумных пределах).

Минусы

• Частично функционал ограничен: если нужны какие-то специфические системные зависимости, WebContainers могут не справиться.
• Не так универсален, как решения уровня GitHub Codespaces. В первую очередь он предназначен для веба.

Где пригодится

• Обучающие примеры фронтенда, демо на конференциях или мастер-классах.
• Когда нужно показать, как работает Angular-компонент или React-хук, а интернет-подключение не самое надёжное.
• Быстрое создание прототипа и проверка идей.

Мой личный опыт и выводы

За 10 лет работы программистом я привык, что «настоящая IDE» должна быть у меня локально, с тщательно настроенными плагинами. Однако чем дальше, тем больше я использую облачные решения. В одних случаях это экономит время на настройке окружения, в других — позволяет быстро работать даже на слабом устройстве, а в третьих — просто удобно для совместной разработки.

• Replit я использую, когда хочу быстро показать фрагмент кода на собеседовании или протестировать идею на маломальном языке, где нет желания ставить компилятор локально.
• CodeSandbox прекрасно подходит для демонстрации и прототипирования фронтенд-проектов. Идеально, если нужно поделиться примером React или Vue-компонента.
• GitHub Codespaces — моё решение для серьёзных проектов, где нужна стабильная облачная среда уровня VS Code, плюс глубокая интеграция с GitHub Actions и репозиториями.
• JetBrains Fleet я «щупаю» как потенциальную легковесную замену IntelliJ IDEA, но с возможностью облачной синхронизации и удалённой мощью серверов JetBrains. Пока рано говорить о полной замене, но направление впечатляет.
• StackBlitz — это «волшебство», когда нужно поднять Node.js в браузере. Очень люблю показывать StackBlitz на воркшопах по фронтенду, потому что всё запускается буквально за секунды.

Какую из этих сред выбрать — зависит от задач и предпочтений. Если вы профессионал, который «сидит в одной IDE 8 часов в день», возможно, вы пока предпочтёте локальные решения. Но всё чаще облачные сервисы дают такую же мощь и удобство, причём сэкономив кучу времени на конфигурации. В любом случае, всем рекомендую попробовать, хотя бы ради эксперимента. Может оказаться, что облачная IDE для некоторых задач станет вашим новым любимым инструментом.

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

В нашем обзоре — 10 библиотек JavaScript, которым в 2025 году пора сказать «До свидания». Для каждого продукта из антирейтинга мы подобрали альтернативные варианты.

Фреймворки, которые утратили актуальность в 2025 году

jQuery

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

Почему прогеры продолжают пользоваться библиотекой? Чисто технически jQuery присутствует во множестве сайтов, сделанных 10-15 лет назад (тогда этот код стал альтернативой VanillaJS). Библиотека создавалась, чтобы сделать язык более гибким и удобным в разработке.

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

Кроме того, современные нативные API JavaScript серьезно улучшились — для подавляющего большинства задач, которые раньше выполнял jQuery, достаточно ванильного JS. Новейшие методики обеспечивают все манипуляции с DOM и взаимодействие веб -страницы с сервером (AJAX-запросы), поэтому необходимость в библиотеке отпадает.

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

Чем заменить

Нативного API JavaScript в ряде случаев будет достаточно для разработки, а для всех остальных ситуаций есть новые версии высокопроизводительных фреймворков React, Vue и Angular.

Lodash

Когда-то эта универсальная библиотека утилит считалась почти обязательной для каждого проекта на JavaScript. Здесь есть String — функция преобразования для обрезки и переноса в верхний регистр; Object — утилита для расширения и слияния; Array — для сжатия и изменения; многие другие фичи, включая глубокое клонирование объектов и манипуляции с массивами данных.

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

Чем заменить

Сегодня многие функции, представленные в Lodash, есть в новой спецификации JavaScript E56. Оператор spread (…), методы Array (map, reduce, filter и прочие) решают те же задачи, которые некогда решал Lodash. В число главных недостатков библиотеки входит также ее большой вес — импорт всего одной функции увеличивает накладные расходы проекта.

Moment.js

Долгое время эта библиотека была основным инструментом для работы с датами. Ее сильными сторонами были:

• способность анализировать, проверять, актуализировать и отображать текущие метки времени;
• работать с календарными датами;
• определять длительность различных процессов;
• поддерживать часовые пояса и т.д.

Сейчас эта библиотека стала слишком тяжелой — даже в мини-формате она занимает 66 КБ, что излишне нагружает устройства, отражается на производительности и быстрой работе UX-функций. Есть более легкие пакеты с теми же функциями.

Чем заменить

Современная альтернатива — date-fns — набор функций для работы с датами на JavaScript, который не входит в библиотеки и работает независимо. Предусматривает модульный импорт — вы можете взять из пакета только то, что требуется для работы, тем самым снижая нагрузку.

Ещё один вариант — Luxon — новая библиотека для работы с датами, созданная командой Moment. Этот инструмент изначально позиционировался как замена предыдущему продукту компании как более мощное, современное и удобное средство. Здесь работа с часовыми поясами реализована без дополнительных расширений, применяется современный подход к написанию кода.

Кроме того, JavaScript Temporal API позволяет работать с датами и временем напрямую, не используя сторонние библиотеки. Поэтому любое из указанных трех решений делает применение Moment.js избыточным и ненужным.

RequireJS

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

Это был самый эффективный способ взаимодействия с зависимостями, особенно ценный в работе с большими приложениями. Совместимость со всеми популярными браузерами, включая Firefox, Safari, Chrome, Opera, а также веб-продуктами на Node, была еще одной сильной стороной библиотеки.

С появлением модулей в ES6 RequireJS утратила статус уникального инструмента. В новой спецификации JavaScript реализован нативный способ определения и импорта модулей. Такой подход делает синтаксис более интуитивным, ускоряет и упрощает разработку.

При этом RequireJS в сравнении с более свежими аналогами слишком сложен в настройке и применении. Он требует от прогеров ручной настройки загрузчика и управления путями зависимостей, что повышает риск ошибок и отнимает кучу времени. Современные загрузчики более расторопные и автоматизированные.

Чем заменить

Помимо ES6, с модулями успешно работает сборщик Webpack, компилируя их в единый файл. Это еще более эффективный инструмент, совместимый с TypeScript и Node.js. При запуске программа обрабатывает модули, выстраивает граф зависимостей между ними и на его основе генерирует общий файл.

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

Backbone.js

Одна из первых библиотек JS (выпущена в 2010), основанная на шаблоне проектирования Model-View-Controller. Предназначена, в основном, для разработки пользовательских интерфейсов и структурирования веб-приложений.

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

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

Кроме того, в Backbone.js нет собственного шаблонизатора, что вынуждает применять другие библиотеки типа Handlebars.js.

Чем заменить

Достойных вариантов замены достаточно. Это React с его архитектурой, основанной на компонентах, и виртуальным DOM. Это и Vue.js с двусторонней привязкой данных и гибкой архитектурой. Это также универсальный Angular с теми же функциями.

Modernizr

Библиотека обнаружения особенностей HTML5 и CSS3 в браузере пользователя. В свое время была крайне полезной и обеспечивала работу приложений в разных браузерах.

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

Чем заменить

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

MooTools

Объектно-ориентированный фреймворк, некогда популярный и безальтернативный. MooTools содержит комплект утилит для работы с DOM, событиями и AJAX-запросами. Сильными сторонами библиотеки был объектно-ориентированный подход и лаконичный синтаксис. Разрабы, предпочитающие писать элегантный и ясный код, были от MooTools в восторге.

Однако постепенно все преимущества фреймворка нивелировались — сообщество так и не дождалось существенных обновлений и перешло на более прогрессивные инструменты. В сравнении с ними MooTools занимает много места, что негативно сказывается на приложениях, где важна производительность (а сегодня она важна везде).

Чем заменить

В современной версии Vanilla JavaScript реализована большая часть функций, представленных в MooTools, в том числе методы для работы с DOM и для обработки событий.

Что касается полноценных библиотек, то MooTools без проблем заменят React или Vue.js. Это простые в освоении и использовании прогрессивные фреймворки для разработки пользовательских интерфейсов.

Script.aculo.us

Библиотека визуальных эффектов и методов управления пользовательским интерфейсом. Была популярна у разработчиков, работающих с анимацией и интерактивными опциями в приложениях. Сильные стороны Script.aculo.us — простота в применении, обширный ассортимент возможностей — перетаскивание, сортировка, слайдеры и т.д.

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

Чем заменить

GreenSock — более мощная, быстрая и универсальная библиотека анимации с огромным выбором эффектов и элементов управления. Работает на стороне клиента и сервера, совместима со всеми браузерами.

Anime.js — еще один гибкий и адаптивный инструмент. Подходит новичкам, поскольку его просто настраивать и легко использовать.

Underscore.js

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

Однако с этим инструментом произошло то же, что и другими библиотеками утилит. Большинство функций, которые были представлены в Underscore.js, теперь реализованы в ES6.

Чем заменить

Новая спецификация JavaScript E56+ поддерживает методы функционального программирования, позволяет манипулировать объектами и массивами данных. Таким образом, все функции Underscore.js доступны непосредственно на JavaScript без всяких посредников. Вывод — переносите код на E56+, он станет чище и проще в поддержке.

Axios

Библиотека для отправки запросов HTTP из браузера или Node.js. Поддерживает множество методов запросов (Get, Put, Delete и другие), загрузку и отправку файлов. Сильные стороны — удобный интерфейс, поддержка Promise API (способ организации асинхронного кода).

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

Чем заменить

Fetch API превосходит конкурента по простоте и гибкости. Он выполняет те же задачи, но оснащен дополнительными функциями — потоковой передачей, отменой запросов, улучшенной обработкой ошибок.

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

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

Делитесь в комментариях, на какие библиотеки перешли! Ну а если хотите детальнее разобраться во всех аспектах Java и JavaScript, заходите в наш тг-канал.

Это моя первая проба пера, так что не судите строго. Сегодня мы разберем одну из самых интересных и, на первый взгляд, сложных тем в JavaScript — Event Loop (или цикл событий). Если вы когда-нибудь задумывались, как браузер умудряется выполнять множество задач одновременно, не зависая при этом, то вы попали по адресу.

Event Loop — механизм, который управляет асинхронными операциями в JavaScript. Он позволяет обрабатывать задачи, не блокируя основной поток выполнения программы. Это особенно важно для создания отзывчивых интерфейсов пользователя и эффективной работы серверов.

Интересно, что Event Loop работает как в браузере, так и в Node.js, но с некоторыми отличиями. В этой статье мы сосредоточимся на том, как это происходит в браузере, и постараемся объяснить всё максимально просто, даже если вы только начинаете свой путь в программировании.

Поехали! 🚀

Как работает Event Loop и из чего состоит

Структура Event Loop

Основная цель Event Loop — циклическое выполнение задач, которые делятся на две категории:

1. Синхронные задачи — выполняются немедленно;
2. Асинхронные задачи — добавляются в очередь и выполняются позже.

Макрозадачи и микрозадачи

Одним из ключевых аспектов работы event loop выступают макрозадачи (macrotasks) и микрозадачи (microtasks). Они представляют собой две очереди задач, которые имеют различный приоритет выполнения.

• Макрозадачи. Выполняются после завершения текущей синхронной задачи. Примеры:Синхронный код; таймеры (setTimeout, setInterval); события пользовательского интерфейса (например, клики мыши); сетевые запросы (например, fetch или XMLHttpRequest).
• Микрозадачи. Выполняются сразу после завершения текущей синхронной задачи, но перед началом следующей макрозадачи. Примеры:Промисы (Promise.resolve(), Promise.reject()).MutationObserver.async/await).

В Node.js также есть event loop, но с небольшими различиями. Например, там используются дополнительные очереди для работы с файловой системой и сетью.

Схема приоритетов выполнения:

1. Сначала выполняется текущий синхронный код;
2. Затем выполняются все микрозадачи в очереди Microtask queue до тех пор, пока очередь не станет пустой;
3. После этого выполняется следующая макрозадача из очереди Macrotask queue и т.д.

Как поведет себя Event Loop в реальной жизни: разбираем код

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

Вложенные промисы и микрозадачи

Порядок вывода:

1. Start
2. First promise
3. Second promise
4. Timeout 1
5. Promise in timeout

Объяснение:

• Сначала выполняется синхронный код (console.log('Start')).
• Затем выполняются микрозадачи (микротаски) — это цепочки промисов.
• После завершения всех микрозадач выполняются макрозадачи (например, setTimeout).

Асинхронные функции и генераторы

Порядок вывода:

1. Async start
2. Main thread
3. Generator timeout
4. After generator

Объяснение:

• Функция asyncFunction начинает выполнение, но останавливается на await, пока не завершится промис, созданный генератором.
• Синхронный код продолжает выполняться (console.log('Main thread')).
• Когда таймер завершается, event loop обрабатывает завершение промиса и продолжает выполнение asyncFunction.

Взаимодействие с DOM и таймерами

Порядок вывода:

1. Initial timeout
2. Button clicked
3. Timeout after click

Объяснение:

• Первый таймер добавляет событие клика на кнопку.
• После выполнения первого таймера происходит имитация клика на кнопку.
• Event loop обрабатывает событие клика и устанавливает второй таймер.
• После завершения всех синхронных задач выполняются все установленные таймеры.

Рекурсивные промисы и рекурсия

Порядок вывода:

1. Outside recursion
2. Recursive 3
3. Recursive 2
4. Recursive 1

Объяснение:

• Вызов recursivePromise(3) запускает цепочку промисов и таймеров.
• Синхронный код (console.log('Outside recursion')) выполняется первым.
• Event loop последовательно обрабатывает каждый вызов рекурсии, начиная с самого глубокого уровня.

Параллельные сетевые запросы и обработка результатов

Порядок вывода:

1. Starting fetches
2. Fetched data from ... (в случайном порядке)
3. All data fetched: [...]

Объяснение:

• Все сетевые запросы начинаются параллельно, но завершаются в разное время из-за случайной задержки.
• Event loop обрабатывает завершение каждого запроса по мере их выполнения.
• После завершения всех запросов выполняется обработчик Promise.all.

Эти примеры показывают, как event loop управляет асинхронными операциями и как важно понимать порядок выполнения кода для правильного написания асинхронных приложений.

Лайфхаки для понимания Event Loop

Используйте визуализацию

Используйте инструменты вроде Chrome DevTools или онлайн-симуляторов Event Loop, чтобы видеть порядок выполнения задач.

Создайте шаблоны

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

Регулярно практикуйтесь

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

Изучите документацию

Изучите официальную документацию по JavaScript и спецификации ECMAScript для более глубокого понимания.

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

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

Фреймворки и библиотеки для разработки интерфейсов

Создание фронтенда, то есть клиентской части программного продукта — неотъемлемый этап разработки сайтов и приложений. Фронтендеры работают с с HTML, CSS, JavaScript, а также используют многочисленные библиотеки с готовыми решениями. Даже новички в курсе, что без фреймворков проекты сегодня не пишутся — это долго, тяжело и непродуктивно. Ниже — наиболее эффективные фреймворки для разработки UI.

React.js

Созданная Джорданом Валке, ведущим программистом самой известной в мире соцсети, библиотека React остается лидером в сфере разработки инфраструктуры на JavaScript UI. На React.js написаны такие проекты, как Skype, PayPal, Airbnb, Dropbox и многие другие.

Популярность библиотеки объясняется вполне объективными причинами:

• Обширное комьюнити. Только на GitHub вы найдете больше 110 тыс. публикаций с тегом «react». Библиотекой пользуются во всем мире, а тысячи профессиональных программистов постоянно обновляют инструменты и актуализируют данные. Если у разработчика появится вопрос, он обязательно найдет на него ответ в сообществе.
• Технологический бэкграунд. Библиотеку создали профи из FB для себя — такие проекты делаются максимально качественно и надежно. Тот факт, что технологии доверяют крупнейшие мировые корпорации, говорит сам за себя.
• Активное взаимодействие с TypeScript. Этот инструмент представляет собой продвинутую версию JS, который со временем стал слишком тяжелым в плане кода. TypeScript лишен многих недостатков Java, поэтому активно применяется в React.js. В общем, в 2025 году фреймворк точно не умрет.
• Версионность. В React, в отличие от Angular или Vue, код, написанный даже несколько лет назад, без проблем запустится на новейшей версии. А если там есть неактуальный элемент, программа сама подскажет, как его исправить.

В React 19 появились новые, еще более мощные компоненты, повышающие производительность и пользовательский опыт:

• Улучшенная поддержка Server Components, с которой более удобно работать с серверным рендерингом и загружать контент в больших проектах;
• Новый API — Actions, который делает более простой и продуктивной работу с формами и интерактивными элементами;
• Директивы preload и preinit обеспечивают предварительную загрузку важных ресурсов, что ускоряет работу приложений;
• Новый канал релизов React Canaries позволяет протестировать некоторые опции React еще до их официального выпуска.

Улучшения произошли и в экосистеме React. Упрощается работа с Redux — библиотекой, которую все чаще используют в связке с React. Инструменты для работы с таблицами и интерфейсами React Table 8 более доступны и производительные.

Vue.js

Еще один мощный, но при этом простой и гибкий в применении инструмент для фронтенд-разработчиков — Vue.js. Согласно экспертным прогнозам, он сохранит свои позиции в топе-3 фреймворков для JavaScript в 2025 году.

Относительно недавно создатели Vue радикально обновили движок и архитектуру. При этом доля TypeScript кода в репозитории приближается к 99%, что расценивается профессиональными прогерами крайне позитивно.

Команда разработчиков Vue.js, возглавляемая Эваном Ю, в свое время заявила, что фреймворк станет самым простым и удобным инструментом из всех существующих. По мнению экспертов, их слова полностью подтвердились.

В числе главных преимуществ фреймворка:

• Подходит для новичков. Для освоения достаточно знания HTML, CSS, JavaScript;
• Небольшой вес. Размер новой заархивированной библиотеки runtime меньше 10 kb;
• В пакет входит виртуальный DOM — объектная модель документа;
• Активное крутое сообщество. Профессионалы помогут, если у разработчика возникнут проблемы.

Количество полноценных приложений, сделанных на Vue.js, превышает 36 тысяч. Это число постоянно растет, и в 2025 году тренд обязательно продлится. В экосистему внедряются новые технологии, например, Vapor Mode, — инструмент, открывающий новые горизонты для разработки высокопроизводительного софта.

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

Появление высокоуровнего фреймворка Nuxt 4 принесет важные улучшения в плане производительности и гибкости разработки. Поддержка Vue 3.3+ в Nuxt 4 улучшает работу с анимацией и межкомпонентные переходы. Пользовательский интерфейс становится более динамичным и плавным.

На фреймворке Vue созданы сайты Ozon, Zoom, Chess (сайт для шахматистов с посещаемостью 20 млн пользователей в месяц), Livestorm — платформа для запуска вебинаров, и многие другие ресурсы.

Angular

Этому мощному фреймворку доверяет Google, что уже говорит само за себя. Множество десктопных и мобильных приложений создано на AngularJS — это крутой инструмент с минимальным риском критических ошибок. На сайте фреймворка создатели призывают разработчиков сосредоточиться на приложениях, а код Angular берет на себя.

И хотя профи считают этот фреймворк более сложным в освоении, чем Vue и React, его функциональность оправдывает все трудности учебного процесса. В 2025 году эволюция Angular продолжится: его последние версии показывают существенные изменения в подходах к реактивности ПО и управлению состоянием.

Новые решения, на которые стоит обратить внимание:

• К числу ключевых нововведений фреймворка относится технология Signals, которая делает взаимодействие с реактивными данными более простым. «Сигналы» актуальны в том случае, когда требуется синхронное обновление UI и оптимизация производительности приложения.
• В Angular 19 компоненты Standalone стали новым стандартом. Теперь они могут использоваться без добавления в модуль. Такое решение упрощает архитектуру приложений и делает подход к коду более прямолинейным.
• Внедрение зависимостей (DI, Dependency Injection) дополнено новой функцией inject() — она заменяет стандартный конструктор, что также упрощает код и делает его более гибким.
• Автоматическая миграция продуктов к новому API — еще один шаг к упрощению и сокращению кода. Это напрямую отражается на производительности современных приложений, в первую очередь, на больших и логически сложных.

Прежние плюсы Angular остались неизменными — расширяемость, взаимодействие с другими фреймворками и инструментами, множество надстроек и дополнений — Auto Validate, Complete, Grid и т.д.

На фреймворке написан сайт британской газеты The Guardian, интерактивные элементы PayPal, самый посещаемый сайт мониторинга погоды Weather.com, фронтенд музыкального ресурса VEVO и многие другие продукты.

Svelte

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

В чем основные фишки Svelte:

• При меньшем весе проекты более производительны — им не требуется виртуальный DOM;
• Фреймворк прост в освоении, поэтому подходит начинающим разработчикам;
• Опытные прогеры обращают внимание на быстроту и стабильность инструмента;
• Анимации в Svelte доступны прямо из коробки — сторонние библиотеки не требуются.

На текущем этапе этот фреймворк рано ставить на одну ступень с React и Vue, но его рейтинг на GitHub постоянно повышается, и в 2025 году растущий тренд точно сохранится.

Фронтенд-разработкой с фреймворком Svetle пользовались такие компании, как Spotify, Ikea, Finance.yahoo, Music.apple и многие другие.

Solid.js

Минималистичный фреймворк, который по производительности и быстроте превосходит все остальные фреймворки из топа. Solid напоминает React, но вместо виртуального DOM использует компиляцию. Проект без проблем компилируется в JavaScript-код, что обеспечивает быстрый рендеринг страницы (трансформацию кода в картинку для пользователя).

В чем плюсы:

• Тонкая реактивность обеспечивает оптимизацию рендеринга в реальном времени;
• Есть бесшовная интеграция со всеми актуальными библиотеками на JS;
• Компоненты фреймворка — стандартные JavaScript-функции: они выполняются однократно для настройки представления, после чего автоматически обновляют интерфейс.

Solid.js, по состоянию на 2025, — идеальный инструмент для одностраничных приложений и продуктов с максимальной интерактивностью (чат-ботов, мессенджеров, панелей управления).

Фреймворк используют такие ресурсы, как 1c.ru, криптовалютная биржа Ape.pro, маркетплейс Майнкрафт Waypoint Studios и другие.

Инструменты для сборки и разработки

По мнению большинства экспертов, в 2025 году ведущим трендом в сборке и разработке на JavaScript будет работа с универсальными мета-инструментами, совместимыми с любыми фреймворками.

Топ наиболее эффективных инструментов этого направления:

• Vite. Локальный сервер разработки от Эвана Ю. В новой версии Vita 6 возможности существенно расширились, в том числе в плане поддержки других фреймворков, помимо Vue. Благодаря модульной архитектуре и новой системе плагинов, улучшилась кастомизация сборки (процесс внесения изменений). С Vite можно использовать несколько фреймворков в одном проекте — для сложных приложений это актуальная опция. Обновления в реальном времени происходят быстро и стабильно.
• Webpack. Сборщик модулей, который компилирует части кода в единый файл. Работает с JavaScript и TypeScript. Несмотря на появление новых инструментов сборки, в 2025 году Webpack останется обязательным инструментом, особенно для работы с масштабными проектами. Он оптимизирует размер и скорость загрузки ресурсов, эффективно выстраивает процессы разработки, в том числе HMR — горячую замену модулей. Плюс обеспечивает совместимость продуктов с различными версиями браузеров.
• Parcel. Главная фишка этого инструмента в том, что его не нужно настраивать и конфигурировать — это делается автоматически. Parcel применяет воркеры — скрипты для многоядерной компиляции, и содержит кэш файловых систем для ускоренной сборки. Есть поддержка из коробки JS, CSS, HTML, поэтому соответствующие плагины не требуются. Модули, которые меняются в процессе разработки, обновляются автоматически.

Тестирование и отладка

В 2025 году в тестировании и отладке продуктов наиболее востребованы следующие инструменты:

• Jest. Самый популярный фреймворк для тестирования кода на JavaScript. Работает с синхронным и асинхронным кодом, интегрируется с React и Vue. В числе основных плюсов — простая настройка и удобное применение. Подходит для проверки и отладки сложных приложений.
• Cypress. Инструмент для автоматизации тестирования, который подходит новичкам. Использует тест end-to-end, покрывая весь путь пользователя, и внедряется в CI/CD — процессы непрерывной доставки и развертывания. Благодаря подробной документации подходит для новичков.
• React Testing Library. Библиотека эффективных инструментов для тестирования пользовательских интерфейсов UI. RTL позволяет абстрагироваться от внутренней логики компонентов и проверяет состояние реального DOM, то есть имитирует действия пользователей, руководствуясь только данными браузера.
• Storybook. Позиционируется как максимально простое средство тестирования и разработки. Создает изолированную программную среду для ускоренного и эффективного процесса.

Инструменты для контроля версий

Актуальные в 2025 средства для контроля созданных разработчиками версий:

• Git. Распределенная VCS (система управления версиями) отслеживает изменения в исходном коде и файлах в совместных проектах. Позволяет править и контролировать версии в процессе разработки. Обладает расширенными возможностями работы с репозиториями.
• GitHub/GitLab. Службы управления репозиториями, которые используются и для управления изменениями в опенсорс-проектах. Оба репозитория обладают полным набором инструментов для контроля и интеграций, обеспечивая эффективную совместную разработку и неограниченное сотрудничество. Обладают встроенными опциями безопасности, которые разработчики могут в любой момент активировать.
• Bitbucket. Аналог GitHub с бесплатным доступом к контролю команды до пяти разработчиков. Подходит для написания частных проектов, обладает гибкостью, совместим со множеством других инструментов, в том числе с Jira, — средой для управления проектами. Интеллектуальный семантический поиск JQL сканирует код по запросу пользователя.

CSS-процессоры и CSS-фреймворки

Инструменты для первичной трансляции кода, актуальные в 2025 году:

• Sass. Препроцессор упрощает написание кода, исключая одинаковые участки или заменяя ключевые элементы синтаксиса одним знаком. Sass считается самым надежным языком расширений CSS, содержит средства импорта и множество других функций.
• Less. Этот препроцессор поддерживает CSS и позволяет разработчикам применять его методы для улучшения и дополнения веб-приложений. В Less встроены логические, строковые, математические функции, а также функции списков.
• Bootstrap. Классический фреймворк для ускоренной верстки со множеством встроенных компонентов. Более 20% всех сайтов в мире создано с его помощью. Автоматически выстраивает адаптивную сетку на базе Flex-модели, создает изображения, поставляется с панелями навигации и другими компонентами.
• Tailwind CSS. Фреймворк, который пользователи называют прогрессивной версией Bootstrap. Содержит обширный каталог утилитарных классов и инструментов для прототипирования, стилизации сайтов и приложений. Легко настраивается, работает с собственными служебными шаблонами, создает сложные адаптивные макеты, в том числе с ориентацией под мобильные устройства.

Инструменты для работы с API и серверной логикой

Эффективная работа с API обеспечивает надежность при обработке информации в приложениях.

В 2025 году топ таких инструментов выглядит следующим образом:

• GraphQL. Язык, описывающий взаимодействие клиента с сервером. Рассматривается как альтернатива стандартного инструмента REST. В сравнении с последним, более удобен в применении, содержит обширный инструментарий.
• Apollo Client. Язык запросов, созданный разработчиками FB. Интегрируется с GraphQL и React для управления состоянием приложения. Предоставляет эффективные инструменты в виде поддержки кэширования, управления состоянием и исправления ошибок. Интегрируется с библиотекой Redux и другими фреймворками.
• Axios. JS-библиотека для работы с HTTP-запросами, а по сути — клиент для работы в браузере и с платформой Node.js. Помогает настроить взаимодействие между frontend и backend.

UI и UX-дизайн

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

Эти инструменты сохраняют свою актуальность в 2025 году:

• Figma. Графический редактор, который остается самым популярным инструментом для проектирования интерфейсов, прототипирования и тестирования. Также это среда взаимодействия команды разработчиков, доступная непосредственно в браузере. Содержит удобные инструменты, может работать в режиме многозадачности.
• Adobe XD. ПО для работы с интерфейсами, анимированием, прототипами сайтов, сервисов и приложений от лидера индустрии. Основной инструмент UX-дизайнеров, желающих создавать юзабельные и современные макеты и делиться результатами работы с командой. Содержит многочисленные инструменты для рисования, создания 3D-эффектов, добавления интерактивных функций и анимации.
• Sketch. Выбор многих профессионалов индустрии UI/UX дизайна. Упрощает разработку интерфейсов благодаря множеству встроенных полезных функций — артбордов, редакторов, поддержкой командной работы в режиме онлайн. Работает только с macOS.

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

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

Рассказывайте в комментариях, какими фреймворками и библиотеками пользуетесь вы. А если хотите найти большей полезной информации про фронтенд — вам сюда.