inngest-setup

Навык Inngest посвящён добавлению durable execution в TypeScript-проект: retry-safe webhook handlers, фоновые задачи, расписания и длительные workflow, которые должны переживать падение отдельного запроса. Источник рассчитан на Node.js 18 и новее; Node.js 22.4+ отдельно рекомендован для сценариев с WebSocket. Для установки подходит обычный пакетный менеджер npm, Yarn, pnpm или Bun, а основой интеграции становится общий клиент Inngest с уникальным идентификатором приложения. Клиент хранит настройки, которые нельзя размазывать по отдельным обработчикам. Обязателен id в виде понятного slug, а eventKey лучше брать из INNGEST_EVENT_KEY. Для production signingKey берётся из INNGEST_SIGNING_KEY; предусмотрен и fallback-ключ для ротации. Дополнительные параметры включают имя окружения для Branch Environments, baseUrl, logger и массив middleware. В версии 4 режим Cloud включён по умолчанию. Поэтому локальный запуск должен явно включать INNGEST_DEV=1 или эквивалентный параметр окружения, а в production должны быть настроены signing key и, при отправке событий, event key. Источник прямо запрещает встраивать секреты и постоянно заданный isDev: true в исходный код: такое значение может незаметно сломать production-поведение. Для типизированных событий навык показывает eventType() со схемой Zod. Имя события и структура данных фиксируются схемой, после чего обработчик получает типизированный event.data, а отправка строится через create(). Это удобно для signup, заказа и похожих доменных событий, но само по себе не проектирует бизнес-модель и не заменяет проверку валидации. При развёртывании полезно разделять клиент, функции и transport, чтобы список функций передавался в serve или worker connection одним явным местом. Есть два режима подключения. Serve endpoint по HTTP подходит serverless-платформам вроде Vercel и Lambda, а также существующим API. Для Next.js App Router источник использует маршрут /api/inngest и экспорт GET, POST и PUT из inngest/next. Для Pages Router применяется default serve(), для Express нужен JSON middleware с лимитом 10mb, потому что Inngest может передавать более крупное состояние функции. Для других сред предусмотрены отдельные адаптеры, включая Fastify, Cloudflare Workers и AWS Lambda; точный способ подключения нужно сверять с документацией нужного фреймворка. Connect по WebSocket предназначен для долгоживущих контейнеров, Kubernetes, Docker и worker-процессов. Важное изменение v4 касается serve: signingKey, signingKeyFallback и baseUrl настраиваются в конструкторе Inngest, а не как прежние параметры serve. Endpoint по умолчанию лучше оставлять на /api/inngest, потому что этот путь используется для автоматического discovery; другой путь потребует отдельной настройки discovery через флаг -u. Если INNGEST_DEV не установлен локально, endpoint может вернуть internal_server_error, журнал — сообщить о работе в Cloud mode без signing key, а dev server — не синхронизироваться с приложением. Навык покрывает TypeScript и перечисленные способы подключения, но не является универсальной инструкцией для Python или Go: для них источник направляет к language-specific документации Inngest. Он также не обещает корректность конкретного workflow без проверки триггеров, переменных окружения, лимитов payload и выбранного runtime. Перед публикацией нужно проверить, что ключи приходят из окружения, dev-режим не утёк в production, endpoint доступен по ожидаемому пути, а служебные функции действительно зарегистрированы в serve либо worker.