Кратко о статье. Я собрал open-source-проект Runtime Lab — интерактивную лабораторию по Node.js, NestJS, PostgreSQL, инфраструктуре и другим темам, которые мне приходится изучать по мере перехода от фронтенда к fullstack-разработке.

Проект доступен как сайт и как репозиторий на GitHub. Сейчас в нём 24 главы на русском и английском языках.

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

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

Код стало проще получить. Понимание — нет

Во время работы над Nneon — платформой, которая позволяет публиковать связанные языковые версии одной записи, — я впервые нормально распробовал Codex. О самом Nneon я писал отдельную статью.

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

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

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

Проблемы начинаются чуть позже: когда нужно выбрать границы сервисов, не потерять данные при повторной доставке сообщения, понять причину роста памяти, заметить N+1, не заблокировать Event Loop тяжёлым вычислением или заранее представить, как приложение поведёт себя под нагрузкой.

То есть работа разработчика не исчезла. Она сместилась от «как написать этот цикл» к «что именно здесь должно происходить, почему это решение не развалится и как я пойму, что оно всё-таки развалилось».

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

Оглядываясь назад, перед разработкой Nneon мне стоило сначала подтянуть backend-теорию. Не потому, что проект сейчас работает неправильно: со своими задачами он справляется. Вопрос скорее в потраченном времени — я в основном генерировал прикладной код и почти ничего не изучал в процессе, кроме создания стандартной архитектуры на фреймворке Nest.

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

Roadmap из YouTube и Event Loop, который не хотел укладываться в голове

Я наткнулся на YouTube на roadmap перехода из frontend- в backend-разработку на Node.js.

Это довольно точно совпало с моей ситуацией: Nneon я писал на NestJS, фронтенд уже не вызывал особых трудностей, а вот знания о runtime, базах данных и инфраструктуре были собраны кусками.

Ссылку на автора я здесь не оставлю. Параллельно он планирует развивать сервис автоматических откликов на HH, а я не хочу дополнительно продвигать инструменты, которые, на мой взгляд, превращают и без того полумёртвый найм в ещё более шумный процесс (скоро единственным способом куда-то устроиться станет написание письма напрямую директору). Но сам roadmap оказался полезным.

Первым серьёзным препятствием стал базовый runtime Node.js: Event Loop, очереди, демультиплексор событий, libuv, разница между готовностью callback и его фактическим выполнением.

Отдельные объяснения я понимал. Но стоило закрыть видео или статью, как знания снова превращались в набор слов: здесь microtask, там poll, где-то рядом process.nextTick, а почему один callback выполнился раньше другого — уже не очень понятно.

Тогда я написал Codex примерно следующее:

Занимаюсь изучением теории Node.js. Инициируй fullstack-проект, на котором я смогу запускать и наблюдать разные механизмы: демультиплексор событий, очередь callbacks, блокировку потока, Event Loop и другие темы.

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

Результат меня удивил.

Первая версия проекта: шесть экспериментов, минимальная теория и временная шкала выполнения.

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

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

Можно было открыть тему, нажать кнопку и посмотреть, что происходит.

Как шесть экспериментов превратились в 24 главы

Сначала в проекте было шесть сценариев, посвящённых Node.js Runtime: порядок Event Loop, демультиплексор, очередь callbacks, блокировка основного потока, Worker Threads, пул потоков libuv и утечка памяти.

Затем я начал добавлять всё, что изучал или встречал в работе. Так появились Promises и BullMQ, closures и heap snapshots, Prometheus и Grafana, Dependency Injection и жизненный цикл запроса в NestJS, микросервисы, SQL и PostgreSQL, Docker, Kubernetes, Redis и HTTP-кэширование.

Позже добавился отдельный раздел по Python и CPython.

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

Сейчас в проекте 24 главы, объединённые в девять разделов. У каждой есть русская и английская версия, то есть всего получается 48 отдельных URL.

В какой-то момент Runtime Lab перестал быть «демкой Event Loop» и превратился в мою личную карту знаний. В отличие от обычного списка закладок, здесь темы приведены к одной структуре и не рассыпаются между десятками статей, видео, репозиториев и заметок.

Как устроена одна глава

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

простая модель → термины → механика → упрощённый код → runtime-код → live trace → production-кейс

Сначала тема объясняется обычными словами. Затем появляется карта runtime и словарь терминов: что относится к JavaScript, что делает V8, где участвует libuv, операционная система, отдельный процесс или база данных.

Термины одновременно попадают в глобальный поиск. Можно ввести в шапке RSS, ACID, nextTick или IoC и найти главы, в которых они используются, а также местами почитать более подробные обьяснения.

Код показывается в нескольких представлениях. Вкладка с теорией отвечает на вопрос «что должно произойти». Упрощённый пример убирает инфраструктурный шум. В runtime-вкладке лежат полные файлы, которые действительно выполняются после нажатия кнопки.

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

В конце остаются популярные заблуждения и несколько вопросов для самопроверки.

Текущее состояние: теория, упрощённый и полный код, метрики процесса и фактический trace одного запуска.

Например, в главе о порядке Event Loop сервер запускает заранее подготовленный сценарий, а интерфейс получает события с timestamp и источником: Call Stack, process.nextTick, microtasks, timers, poll, check и итоговый результат.

Важно, что страница не предлагает выучить один магический порядок навсегда. Поведение зависит от контекста запуска, версии runtime и самого сценария. Даже взаимный порядок setImmediate() и setTimeout() зависит от того, где они были зарегистрированы, а начиная с Node.js 20 изменилось расположение обработки timers относительно poll-фазы.

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

Над экспериментом выводятся uptime процесса, задержка Event Loop, utilization и время HTTP-запроса от браузера до сервера. Для учебной страницы это немного избыточно, но мне хотелось постоянно напоминать себе, что runtime — не абстрактная схема из статьи. Это работающий процесс, состояние которого можно измерять. Node.js предоставляет для этого, в частности, eventLoopUtilization() и monitorEventLoopDelay() из perf_hooks.

Почему здесь вообще понадобился AI-агент

Главная польза Codex в этом проекте не в том, что он «знает Node.js лучше всех». Это как раз опасная мысль.

Польза в другом: агент резко удешевляет создание учебного инструмента вокруг сложной темы.

Раньше идея «сделать отдельный интерфейс для сравнения main thread и Worker Thread, добавить trace, полный код, график и безопасное завершение процесса» почти наверняка осталась бы заметкой в backlog. Теперь такой стенд можно получить за несколько итераций, а оставшееся время потратить на проверку модели и уточнение вопросов.

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

Поэтому я постепенно добавил несколько правил. В главе должны быть ссылки на первичные источники. Полный код должен быть доступен рядом с объяснением. Эксперимент не запускается автоматически. Для неоднозначных тем отдельно описывается контекст, в котором справедлива упрощённая модель. А ожидаемый результат можно сравнить с фактическим trace.

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

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

Отдельные режимы для разработки и публичного сайта

Некоторые эксперименты сами по себе потенциально неприятны для сервера.

Например, глава об утечке памяти удерживает Buffer, массивы и другие объекты, а затем позволяет остановить процесс, освободить ссылки, вызвать GC и скачать heap snapshot.

Поэтому у проекта есть два профиля.

В dev-режиме ограничения мягче: memory leak может удерживать до 512 MB и автоматически ставится на паузу через 120 секунд.

В публичном prod-режиме включены rate limit, ограничение параллельных запусков и более строгие лимиты: до 256 MB памяти и принудительное завершение процесса через 60 секунд.

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

Для Docker, Kubernetes, PostgreSQL, Redis и Python используется похожий принцип: по возможности запускается настоящий сценарий, а когда внешняя инфраструктура недоступна, теория и безопасная демонстрация остаются доступными.

PostgreSQL-запросы, например, могут выполняться при наличии DATABASE_URL, а BullMQ использует настоящий Redis при переданном REDIS_URL. Python-сценарии запускаются в отдельном CPython-процессе. При этом для чтения главы не нужно предварительно разворачивать половину интернета у себя на компьютере.

Почему одной такой платформы всё равно недостаточно

Самообразование — это, по сути, отдельная дисциплина.

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

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

Одной кнопки «Запустить» недостаточно, чтобы понять Event Loop. Нужно посмотреть несколько объяснений от разных авторов, прочитать документацию, изменить сценарий локально, сломать ожидаемый порядок, попробовать сформулировать механику своими словами и затем встретиться с ней в настоящем проекте.

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

Поэтому я не рассматриваю Runtime Lab как замену курсам, YouTube, документации или pet-проектам.

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

Что получилось в итоге

На текущем этапе Runtime Lab содержит 24 главы по Node.js, NestJS, базам данных, инфраструктуре, кэшированию и Python. В каждой теме я стараюсь соединять простое объяснение, полный код, production-контекст и наблюдаемое выполнение.

Весь проект написал Codex. Но это не история о том, как нейросеть сама создала курс и теперь мне ничего не нужно знать.

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

Проект полностью открыт. Его можно посмотреть на сайте, а исходники находятся на GitHub.

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

Скорее всего, через несколько месяцев это всё так и останется моим персональным учебным стендом. Но даже в таком виде эксперимент уже оказался полезным: вместо очередной папки с разрозненными примерами у меня появилось место, где теория встречается с кодом и не заканчивается на фразе «ну, примерно так работает Event Loop - фазы, таски».

Код действительно стал дешевле.

Понимание, любопытство и здоровое недоверие — пока нет.