Контракт-дривен фреймворк для AI: как Traverse позволяет собирать бизнес-капабилити на WASM и запускать их в браузере, на edge и в облаке

Я — Денис Шохирев, Agentic AI Systems Architect из Фрайбурга, управляю DennisCraft AI Studio. Мой стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. Недавно столкнулся с типичной болью: бизнес требует запускать одну и ту же AI-логику — например, скоринг сделки или фильтрацию заявок — сразу в браузере (privacy, latency), на edge (IoT) и в облаке (масштаб). Переписывать пайплайны и тесты под каждую платформу — путь к раздутию кода и потерям на валидации.

Контракт-дривен подход: что я закладываю в Traverse

В основе фреймворка — не просто код, а строгий контракт между входами, логикой и выходами бизнес-капабилити. Это не YAML-описание, а типизированная схема (например, на TypeScript или OpenAPI), которая валидируется на этапе сборки и тестирования. Такой контракт помогает держать одну бизнес-функцию валидной сразу для нескольких рантаймов.

Проблемы классических AI пайплайнов

• Логика размазана по back, front, edge — сложно гарантировать идентичность поведения.
• Тесты часто не покрывают edge-случаи: баги проявляются только в проде.
• Сложно внедрять обновления без риска сломать что-то в одной из сред.

Пример контракта на TypeScript

export interface DealScoringInput {
  dealId: string;
  features: Record<string, number>;
}

export interface DealScoringOutput {
  score: number;
  riskLevel: 'low' | 'medium' | 'high';
}

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

WASM: один бинарь для всех сред

WebAssembly (WASM) позволяет компилировать бизнес-логику (например, на Rust, Go или AssemblyScript) в универсальный бинарь, который работает в браузере, на edge (например, Cloudflare Workers) и в облаке (Supabase Edge Functions). В моих последних проектах миграция логики скоринга на WASM позволила:

• Убрать дублирование кода (не держать версию на JS для фронта и на Python для облака).
• Обеспечить единое поведение: тесты проходят один раз, затем бинарь деплоится везде.
• Упростить аудит безопасности — одна точка контроля.

Базовый WASM-проект на Rust

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn score_deal(features: &JsValue) -> JsValue {
    // Десериализация, скоринг, сериализация
}

Компиляция через wasm-pack build даёт модуль, который грузится как в React-приложении, так и в edge-функции.

Тестирование и валидация: что реально ловит баги

Реальный прод требует не только юнит-тестов, но и статического анализа и runtime-ограничений. В одном из кейсов за последний квартал semgrep и bandit поймали уязвимость CWE-89 (SQL-инъекция) в сгенерированном LLM-коде для Postgres слоя. Без автоматического контракта и единого рантайма эта уязвимость бы ушла на edge, где мониторинг слабее.

Интеграция с CI и Supabase

semgrep --config=auto src/
bandit -r src/
docker build -t dealscore:wasm .
supabase functions deploy dealscore

CI/CD пайплайн гарантирует, что только прошедший тесты и анализ бинарь попадает в edge/cloud.

Edge, браузер и облако: сравнение среды

Контракт-дривен + WASM позволяют запускать одну и ту же бизнес-логику, не переписывая её под каждую среду.

FAQ

Какой стек лучше подходит для сборки WASM-капабилити?

Я использую Rust — он даёт стабильные бинарники и строгую типизацию. AssemblyScript быстрее учить фронтам, но требует больше ручной валидации.

Можно ли запускать LLM внутри WASM?

Только мелкие модели или inference через API. Большие модели (GPT-3+) не поместятся в браузер или edge-функцию.

Как валидировать контракты между компонентами?

Используйте tRPC, Zod или OpenAPI — схемы синхронизируются между клиентом и сервером, ошибки ловятся на этапе сборки.

Как закрывать security-дыры при генерации LLM-кода?

semgrep, bandit, gitleaks — обязательная часть CI. Не пускайте ни один auto-gen код без анализа. В моих пайплайнах bandit ловил SQL-инъекции от LLM на этапе ревью.

Что делать с миграциями, если контракт меняется?

Сначала — алиасинг/версионирование контрактов (например, v1/v2 endpoint), потом постепенный rollout. Никогда не ломайте контракт сразу — клиенты на edge и в браузере могут обновиться не одновременно.

У вас в проде уже есть кейсы, где бизнес-логика должна быть одинакова в браузере, на edge и в облаке? Как вы ловите рассинхрон между средами: на CI, в тестах или уже по баг-репортам от пользователей? Я провожу бесплатный 30-мин аудит стека для DACH-команд, строящих AI в регулируемых рынках. Пишите в LinkedIn или @ger_dennis_ai.