Foundation

Foundation - это попытка nmxmxh схлопнуть цепочку преобразований в типичном веб-стеке (строки SQL -> структуры Go -> JSON -> HTTP -> интерфейсы TypeScript -> состояние React) в единый контракт, из которого читает каждый слой. Достаточно описать мутацию один раз в Protobuf или Cap'n Proto, и схема сгенерирует маршруты Go, типы TypeScript и структуры данных в бинарном представлении для передачи без копирования (zero-copy) через каждую границу. Проект находится в версии 0.0.1, о чём README прямо и говорит.

Структура

Семь пакетов, разделённых по границам слоёв, а не по функциональности. server-kit - это бэкенд на Go: шина событий, воркеры, база данных, отказоустойчивость, наблюдаемость (observability) и Hermes. runtime-transport отвечает за транспортный уровень клиента на TypeScript: командная шина, формирование конвертов (envelopes), WebSocket с откатом на HTTP. runtime-sdk - ядро на Rust/WASM вокруг управляющего буфера размером 4 КБ и разделяемой арены памяти. runtime-native - оболочка на Tauri для безопасного хранения, дескрипторов GPU и доступа к устройствам. frontend-kit, ui-minimal и config-contracts закрывают хранение в IndexedDB, общие примитивы React и межъязыковые схемы конфигурации. Под капотом: PostgreSQL для надёжного хранения данных, Redis для координации, Protobuf для контрактов, Cap'n Proto для границ с нулевым копированием.

Hermes - компонент, которым README гордится больше всего. Он поддерживает локальные для узла, ограниченные по памяти и индексированные модели чтения, которые проецируют мутации базы данных в реальном времени, благодаря чему операции чтения вообще не обращаются к Postgres. Приведённый бенчмарк показывает фильтрацию по предикату через слияние колоночных битовых карт примерно за 34 мкс и 2 аллокации против примерно 7.8 мс и более 10 000 аллокаций при последовательной выборке записей - заявлено ускорение в 229 раз, по собственным замерам автора.

Плоскости производительности

Вместо одной модели выполнения Foundation выделяет семь каналов и связывает с каждым измеренную стоимость:

1. Direct dispatch        10-30 ns/op     (same-process, zero-alloc)
2. Binary frames          20-80 ns/op     (borrowed views)
3. Generated protobuf     ~370 ns/op      (typed cross-process)
4. gRPC                   20-30 µs/op     (network machinery)
5. JSON                   ~30 µs/op       (compatibility)
6. Native FFI/SHM         (varies)        (trusted compute)
7. Browser + WASM + SAB   (platform)      (where supported)

Заявленное правило: самый быстрый канал не должен платить за накладные расходы канала совместимости, а регрессии этих показателей должны отлавливаться в CI до попадания в кодовую базу. Каналы задуманы как уточнения единого контракта, выбираемые в зависимости от возможностей среды, а не семь моделей программирования на выбор разработчика: один и тот же вызов работает через SharedArrayBuffer, если браузер его поддерживает, и откатывается на JSON, если нет. Что касается рантайма - см. webassembly.

Аспект ИИ-агентов

В Foundation прямо говорится, что такая структура выбрана отчасти потому, что значительную часть кода пишут агенты. В репозитории есть AGENTS.md, операционный контракт агента, модель угроз ИИ, а также .cursorrules / .clauderules в генерируемых проектах. На практике на каждом коммите запускается более 40 автоматических проверок (Practice Controls) - границы циклов, изоляция тенантов, расхождение контрактов, безопасность конкурентности, пороги сложности. Аргумент прост: автоматически проверяемые ограничения заменяют комментарии в код-ревью и не дают агенту отклоняться от правил.

Это та же ставка, что и в agent-built-deterministic-tools: один раз вложить усилия в детерминированные проверки, а затем ограничить результаты работы агента только тем, что проходит эти проверки. Это также прямой ответ на constraint-decay-backend-agents, где качество работы агентов падает по мере накопления структурных ограничений продакшена: Foundation делает ограничения проверяемыми машиной на этапе компиляции, а не соглашениями в стайлгайде. Автор утверждает, что сам проверяет и утверждает все изменения, но многие модули, тесты и справочные документы написаны агентами.

make generate-contracts      # protos -> Go/TS
make verify                  # full CI suite
make check-practice-controls # practice matrix
make check-doc-references    # link validation

Создание каркаса проекта запускается через точку входа Node из родительской директории репозитория:

node foundation/cmd/ovasabi/bin/ovasabi.js init --profile=performance --name=my-app \
  --foundation-dir foundation --skip-license

Команда update вливает изменения апстрима в базовых модулях в существующий проект. Сгенерированные проекты должны использовать Foundation через границы пакетов: прямой импорт foundation/*/ts/src или foundation/*/go считается грубой ошибкой.

Опасения

Версия 0.0.1, один автор, все данные - только собственные замеры. В README не указана конкретная лицензия, есть только ссылка на файл LICENSE. Каждая цифра здесь - это бенчмарк самого проекта на его собственной нагрузке, а самая впечатляющая (ускорение в 229 раз на фильтрах предикатов) сравнивает Hermes с базовой реализацией выборки записей, исходников которой читатель не видит. Стек, к которому проект вас привязывает, огромен: Postgres, Redis, Protobuf, Cap'n Proto, Rust/WASM, Tauri, React. Переход на этот субстрат означает принятие всего стека целиком, поэтому цена отказа от него равна переписыванию всего приложения. В самом README в разделе "Work in Progress" указано, что шаблоны агентской разработки всё ещё проверяются на практике.

За проектом стоит следить, но пока не использовать: кодогенерация contract-first в сочетании со строгими бюджетами производительности - здравая идея, и language-choice-for-agents приводит доводы именно в пользу такого направления. Однако проект в версии 0.0.1 с непонятной лицензией пока не годится в качестве фундамента.

Repo: https://github.com/nmxmxh/foundation