Сжатая архитектура системы (2026)
Связка Tauri + SolidJS + AG Grid + Go + Postgres — это золотое сечение современной инженерии. Она дает максимальную скорость работы интерфейса (за счет SolidJS и AG Grid), злую производительность сервера (за счет Go) и абсолютную надежность данных (за счет Postgres), оставаясь при этом ремонтопригодной по кадрам на рынке РФ.
=====================================================================================================
СХЕМА АРХИТЕКТУРЫ СИСТЕМЫ (2026)
=====================================================================================================
[ СЛОЙ ДОСТАВКИ И UI-РЕНДЕРИНГА: TAURI ДЕСКТОР-КЛИЕНТ ]
│ Физика: Изолированное нативное окно ОС macOS (через системный движок WebKit/Safari).
│ Оверхед по оперативной памяти: ~30-40 МБ (в отличие от 150+ МБ у Electron).
│
├── [ Слой интерфейса: SolidJS ]
│ └── Назначение: Управление состоянием (стейтом) через сигналы (Signals).
│ └── Физика процесса: Нет виртуального DOM. Компилятор превращает код в прямые мутации
│ конкретных текстовых нод в DOM-дереве. Обновление ячейки не вызывает перерисовок соседа.
│
└── [ Движок таблиц: AG Grid (Обертка под SolidJS) ]
└── Назначение: Замена Oracle Forms для операторов интенсивного ввода данных.
└── Физика процесса: Строгая виртуализация строк и колонок. Если в памяти 100 000 строк,
в DOM-дереве физически существуют только 30 строк, которые видны на экране.
Обеспечивает скроллинг и горячие клавиши (Excel-style) на частоте 60-120 FPS.
│
│ Протокол связи: Постоянный двусторонний асинхронный канал (WebSockets / gRPC-Web)
│ Трафик: Компактный JSON (минимум оверхеда на заголовки, в отличие от REST HTTP)
▼
[ СЛОЙ БИЗНЕС-ЛОГИКИ И ОРКЕСТРАЦИИ: GO (GOLANG) БЭКЕНД ]
│ Физика: Единый скомпилированный статический бинарник под Linux/Unix.
│ Управление памятью: Высокопроизводительный Garbage Collector с микропаузами <1 мс.
│
├── [ Сетевой роутер / Ядро: Chi / Fiber ]
│ └── Назначение: Прием WebSocket-соединений от операторов и директоров, парсинг JSON.
│
├── [ Модуль мягких распределенных блокировок: In-Memory Storage / sync.Map / Redis ]
│ └── Назначение: Воспроизведение механизма «SELECT FOR UPDATE» из Oracle Forms без насилия над БД.
│ └── Физика процесса: При старте редактирования ячейки оператором, ID строки падает в кэш
│ памяти бэкенда на 60 секунд. Другие операторы мгновенно получают по WS статус «занято»
│ и строка в их AG Grid блокируется (сереет). Диск и СУБД при этом вообще не трогаются.
│
└── [ Драйвер СУБД: pgx (Нативный пуллер для Postgres) ]
└── Назначение: Управление пулом долгоживущих соединений к БД (Connection Pool).
└── Физика процесса: Забудь про ORM-магию (типа Hibernate). Используется кодогенератор `sqlc`.
Запросы пишутся на чистом, злом SQL. На этапе компиляции они превращаются в прямые,
типобезопасные вызовы к Postgres без рантайм-рефлексии.
│
│ Протокол связи: Нативный бинарный протокол PostgreSQL (v3) через Unix-сокет / TCP
│ Транзакционность: Короткие, изолированные транзакции (Read Committed / Serializable)
▼
[ СЛОЙ ХРАНЕНИЯ ДАННЫХ И ЦЕЛОСТНОСТИ: POSTGRESQL ]
│ Физика: Реляционная СУБД. Вся бизнес-логика вынесена в Go-код (Postgres плох в процедурах
│ по сравнению с Oracle PL/SQL). База занимается только ACID, диском и индексами.
│
├── [ Оптимистичное версионирование (OCC) ]
│ └── Механика: Каждая таблица имеет поле `version INT`. При фиксации изменений от Go,
│ запрос делает `SET version = version + 1 WHERE id = X AND version = current_version`.
│ Защищает от коллизий, если два оператора смогли обойти мягкую блокировку в памяти.
│
└── [ Индексы и Секционирование ]
└── Механика: Тяжелые биллинговые таблицы бьются физически на диске по датам (Partitioning).
Поиск идет по индексам `B-Tree` (для точечных данных) и `BRIN` (для тяжелых хронологических логов).
=====================================================================================================