FTS из Python, Go, Java и других языков
FTS не требует переписывать parser на каждом языке. Есть три границы.
1. JSON CLI
Самый быстрый путь для Python:
import json
import subprocess
result = subprocess.run(
["fts", "run", "discount.fts", "--utility", "Рассчитать скидку", "--input", "purchase.json"],
check=True,
capture_output=True,
text=True,
)
payload = json.loads(result.stdout)
print(payload["result"])
Плюсы: одна reference implementation, простой rollout. Минусы: запуск процесса дороже library call; для высокой нагрузки нужен worker или service boundary.
2. Отдельный FTS service
Node.js загружает модели один раз и предоставляет внутренний API. Go/Java-сервис отправляет только типизированный snapshot. Плюсы: контролируемая версия runtime, метрики и кэш. Минусы: сеть, отказоустойчивость и contract versioning.
3. Канонический JSON
Можно скомпилировать .fts в build pipeline и поставлять FtsDocument как
data artifact. Хост пишет маленький adapter для структур, форм или собственной
исполняющей среды. В этом случае semantic parity нужно подтверждать общим набором
fixtures: два runtime обязаны давать одинаковые результаты и diagnostics.
Когда выбрать что
| Сценарий | Граница |
|---|---|
| Локальная утилита или CI | CLI |
| Node.js backend | Library API |
| Browser UI | @digitable/fts/browser |
| Несколько сервисов с большой нагрузкой | Internal FTS service |
| Собственный runtime в Rust/Go | Canonical JSON + conformance suite |
| AI agent | MCP |
Версионирование
Версионируйте отдельно:
- surface syntax;
- canonical schema (
fts/1, будущие версии); - runtime package;
- конкретную бизнес-модель.
Не меняйте canonical field молча. Старые functors и apply во внутреннем wire
format существуют ради совместимости, хотя публичная терминология использует
морфизмы.
Упражнение
Вызовите одну модель из Python или shell. Проверьте успешный JSON и ошибочный stderr. Затем измерьте накладные расходы запуска процесса, чтобы осознанно решить: оставить CLI или поднять долгоживущий host.
