Как мы ускорили холодный старт TypeScript SDK на 50% с помощью бандлинга

Биткойн Налоги и криптовалюта

TypeScript SDK компании Dagger долгое время испытывал проблему медленного холодного старта, что доставляло неудобства разработчикам. Время инициализации составляло от 20 до 30 секунд, а при постоянных вызовах TypeScript модулей это превращалось в заметный тормоз рабочего процесса. В процессе разработки каждый разработчик мог делать сотни таких вызовов, поэтому задержки серьёзно снижали продуктивность и создавали дополнительное раздражение. В данной статье подробно рассматривается, какие меры были приняты для оптимизации процесса, как команда справилась с комплексными техническими вызовами и каким образом удалось сократить время инициализации вдвое благодаря внедрению эффективного бандлинга. SDK Dagger состоит из двух ключевых частей.

Первое — это клиентская библиотека, которая позволяет писать код для взаимодействия с Dagger API. Второе — инструменты, предназначенные для публикации собственных функций Dagger. Ранее при каждой инициализации происходило копирование полного TypeScript SDK в рабочий модуль, содержащий код конвейера и манифест dagger.json. В результате при каждом вызове Dagger Engine приходилось выполнять комплексный набор операций.

Среди них были сборка клиентской библиотеки для связи с движком, установка зависимостей SDK, установка пакетов модуля и выполнение внутреннего скрипта, который либо запускал определённую функцию, либо регистрировал их для последующего использования. Все эти шаги запускались до начала исполнения кода, что и приводило к существенным задержкам. Сложности с производительностью усугублялись структурой зависимости проекта. SDK и пользовательский модуль имели общее дерево зависимостей. Если библиотеке SDK требовалась конкретная версия, например GraphQL-client vX, но в модуле была указана несовместимая версия vY, это вызывало конфликты на этапе установки пакетов.

В худших случаях такие рассогласования могли не выявиться сразу и привести к сбоям во время выполнения. Кроме того, SDK должен был поддерживать разные среды выполнения — Deno, Bun и Node.js — а также множество менеджеров пакетов: npm, pnpm, несколько версий yarn. Каждая из этих платформ обладала собственными особенностями конфигурации и поведения, что создавал дополнительный уровень сложности. Рассмотрим подробнее технические вызовы.

Во-первых, дрифты в конфигурации среди Bun, Deno и Node.js требовали написания специальных скриптов для корректного взаимодействия с каждым из рантаймов. При этом для Deno необходимо было включать экспериментальные фичи, чтобы SDK стабильно работал. Менеджеры пакетов также добавляли хаоса: установить yarn было сложнее из-за необходимости включения Corepack, а pnpm требовал дополнительного рабочей конфигурации. Кроме того, скорость загрузки зависимостей значительно варьировалась: pnpm оказывался быстрее примерно в полтора раза по сравнению с npm и yarn, что позитивно сказывалось на пользовательском опыте.

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

Команда переключилась с npm на yarn, ограничила установку только продакшн-зависимостями, повысила эффективность использования кэша Dagger, а также реструктурировала этапы инициализации SDK. Несмотря что данные меры добавили 2-3 секунды к скорости загрузки, это было недостаточно и не стабильно для всех ситуаций. Настоящий прорыв случился с идеей интеграции утилиты tsx — TypeScript командной строки — прямо в образ Dagger Engine. Такой подход позволил избежать необходимости пересобирать и транспилировать TypeScript-код на лету во время каждого запуска. В результате с холодным кэшем время инициализации улучшилось на 7-10 секунд.

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

Главным прорывом стало решение бандлить весь TypeScript SDK целиком. Вместо того, чтобы копировать весь каталог SDK (около 155 мегабайт) в каждый пользовательский модуль и загружать десятки зависимостей, команда создала компактный бандл размером порядка 4.5 мегабайт. Такой сокращённый пакет стал легче для загрузки и установки, уменьшил количество файлов в директории модуля, а также практически ликвидировал прежние проблемы с согласованностью зависимостей. В ходе работы над бандлингом рассматривались разные инструменты.

В итоге был выбран Bun bundler из-за скорости и эффективности. Однако он могла упаковывать только JavaScript, поэтому для создания типовых деклараций TypeScript применялся Rollup — популярный бандлер, часто используемый для упаковки JS/TS кодов. В процессе разработки выявились проблемы при анализе кода пользовательских модулей, связанные с такими технологиями как декораторы и промисы. Проведённые исследования показали, что ошибки вызваны включением TypeScript в сам бандл. После его исключения и организации отдельной загрузки TypeScript всё заработало как надо.

Для автоматического обновления клиента SDK при изменении зависимостей в пользовательских модулях или появлении новых пакетов была настроена специальная логика на уровне конфигурации tsconfig.json, ограничивающая перезагрузку до отдельных частей SDK. Такая стратегия помогла сохранить скорость и корректность работы при обновлениях. В конечном счёте оптимизированный бандл включает всего пять файлов: сжатый JavaScript-код, типовые определения, динамически генерируемого клиента, а также вспомогательные скрипты для телеметрии и управления импортами. Единственная внешняя зависимость, которую теперь требуется загружать отдельно, — это сам TypeScript.

Положительный эффект от оптимизации впечатляет. Среднее время инициализации сократилось с приблизительно 21 секунды до 11 секунд. Хотя 10 секунд экономии может показаться незначительной величиной, необходимо учитывать частоту вызовов — десятки или сотни раз в течение дня в разгар интенсивной разработки. Благодаря изменению пользователи получили ощутимую выгоду, что подтвердилось отзывами и более плавным опытом работы. Dagger — это платформа для создания и выполнения инженерных рабочих процессов, позволяющая автоматизировать тестирование, сборку, код-ревью и многое другое.

Благодаря быстрой и эффективной работе SDK разработчики могут интегрировать свои проекты и писать модули быстрее, чем когда-либо. Нововведения с бандлингом повышают привлекательность SDK и делают ежедневную работу более комфортной. Внутренний опыт команды Dagger наглядно демонстрирует, что глубокое понимание технических деталей, постоянные эксперименты и готовность пожертвовать частью гибкости ради стабильности открывают дверь для значительных улучшений. Внедрение современного бандлинга определённо стало шагом вперёд в эволюции разработческой платформы, поднимая планку производительности и качества взаимодействия с продуктом.