Архитектура

Apostol CRM объединяет два фреймворка в единый бэкенд: высокопроизводительный HTTP-сервер на C++20 и движок бизнес-логики на PostgreSQL. Вместе они дают 418 REST API эндпоинтов, аутентификацию OAuth 2.0, движок рабочих процессов, WebSocket pub/sub, фоновую обработку и файловое хранилище -- и всё это в одном исполняемом файле.

Обзор

Без PHP, Python или Node.js. HTTP-запросы идут напрямую из C++ в PostgreSQL -- ноль промежуточных слоёв, задержка менее миллисекунды.

Поток запроса

Слой C++ обрабатывает разбор HTTP, TLS, пул соединений, WebSocket, проверку JWT и асинхронный ввод-вывод. Слой БД обрабатывает бизнес-логику, маршрутизацию REST, контроль доступа, переходы рабочих процессов и хранение данных. Они взаимодействуют через libpq -- один цикл событий, без потоков.

Система модулей

C++-сервер собирается из независимых модулей. Каждый модуль -- это отдельный репозиторий на GitHub, который можно включить или исключить.

Workers -- обработка HTTP/WebSocket-запросов

Порядок регистрации воркеров имеет значение (срабатывает первое совпадение):

static inline void create_workers(Application& app)
{
    // Auth endpoints: /oauth2/*
    if (app.module_enabled("AuthServer") && app.has_db_pool())
        app.module_manager().add_module(std::make_unique<AuthServer>(app));

    // REST API: /api/* (with auth)
    if (app.module_enabled("AppServer") && app.has_db_pool())
        app.module_manager().add_module(std::make_unique<AppServer>(app));

    // Static files: /* (last -- catches everything else)
    app.module_manager().add_module(std::make_unique<WebServer>(app));
}

Helpers -- фоновые модули в helper-процессе

Processes -- независимые фоновые демоны

Архитектура базы данных

Слой PostgreSQL построен по двухуровневой схеме с четырьмя схемами:

Типичный запрос проходит через все четыре слоя:

POST /api/v1/sensor/list
  -> rest.sensor('/sensor/list', payload)
    -> api.list_sensor(search, filter, limit, offset, orderby)
      -> SELECT * FROM kernel.ObjectSensor (view)
        -> JOIN db.sensor, db.document, db.object, ...

Модули платформы (26)

db-platform предоставляет 26 переиспользуемых PL/pgSQL модулей:

• Ядро: entity, class, type, object, document, reference
• Аутентификация: session, user, oauth2, token
• Рабочие процессы: state, method, transition, action, event
• Контроль доступа: ACU (на уровне класса), AOU (на уровне объекта), AMU (на уровне метода)
• Инфраструктура: job, message, file, log, notification

Три роли базы данных

Система сущностей

Apostol CRM поставляется с 30 бизнес-сущностями (клиенты, счета, платежи, подписки, устройства и другие). Каждая сущность следует стандартной конвенции из 8 файлов:

entity/object/document/myentity/
├── table.sql       # CREATE TABLE, индексы, триггеры
├── view.sql        # 3 представления в kernel (данные, доступ, полный объект)
├── routine.sql     # Процедуры Create*/Edit*/Get*
├── api.sql         # Представления схемы api + 6 CRUD-обёрток
├── rest.sql        # REST-диспетчер (6 стандартных маршрутов)
├── event.sql       # 9 обработчиков событий
├── init.sql        # Рабочий процесс: класс, тип, состояния, методы, переходы
└── create.psql     # Мастер-скрипт установки

Каждая сущность наследуется либо от document (бизнес-объекты с жизненным циклом и доступом на основе областей), либо от reference (справочные/каталожные данные). Создание новой сущности означает создание этих 8 файлов и их привязку к родителю.

Движок рабочих процессов

У каждой сущности есть встроенный автомат состояний. Жизненный цикл по умолчанию:

       ┌────── restore ───────┐
       v                      |
  [Created] --enable--> [Enabled] --disable--> [Disabled]
       |                    |                       |
       |--disable-->  [Disabled]                    |--enable--> [Enabled]
       |                    |                       |
       |--delete-->   [Deleted]  <--delete--   [Deleted] <--delete--

Четыре типа состояний: created, enabled, disabled, deleted.

Рабочий процесс можно настроить под каждую сущность, добавляя собственные состояния, методы, переходы и события. Например, у зарядной станции могут быть available, unavailable и faulted как подсостояния в рамках типа состояния enabled. См. руководство Настройка рабочих процессов.

Композиция модулей

libapostol спроектирован как конструктор модулей. Вы выбираете только нужные модули:

• Минимальная (без базы данных): только WebServer -- раздача статических файлов + healthcheck
• HTTP-шлюз: PGHTTP + WebServer + PGFetch -- маршрутизация HTTP-запросов в PostgreSQL
• Полный бэкенд: все воркеры + helpers + процессы -- полная платформа с аутентификацией, файлами, WebSocket и фоновыми задачами
• Своя конфигурация: любая комбинация. Каждый модуль самодостаточен

Проекты в продакшене

Проекты, построенные на той же архитектуре: