Архитектура

    Headless Telematics: готовый бэкенд, ваш интерфейс

    Headless Telematics — архитектурный подход, при котором функции телематического бэкенда доступны через документированные API, а интерфейс поставщика необязателен: команда строит собственный интерфейс поверх готового ядра. Веб- или мобильный интерфейс, сценарий внутри бизнес-процесса, интеграция с операционной системой — выбор за вами, а бэкенд остается тот же.

    Смотреть документацию Перейти к Composable Telematics
    Документированный APIIoT Query — доступ на чтениеИнтерфейс — ваш контроль
    Запрос · SQL
    SELECT device_id, device_time, lat, lng
    FROM raw_telematics_data.tracking_data_core
    WHERE device_id = 104
    ORDER BY device_time DESC
    LIMIT 1;
    Ответ · строка результата
    { "device_id": 104,
    "device_time": "2026-07-21T14:02:11Z",
    "lat": 43.238, "lng": 76.889 }
    200 · raw_telematics_data · доступ на чтение
    Определение

    Что такое Headless Telematics

    Headless Telematics разделяет продукт на две части: телематический бэкенд с данными и логикой, открытый через документированные API, и интерфейс, который проектирует команда, строящая продукт. Ядро остается одно, а поверх него можно построить любой интерфейс. Navixy работает по этому принципу: возможности телематического бэкенда доступны через документированные API, а точный состав операций для каждого сценария описан в документации.

    • Постройте портал, мобильное приложение, встроенный в бизнес-процесс сценарий или интеграцию с системой операционного управления — выбор интерфейса не ограничен одним вариантом.
    • За пользовательский опыт, доступность, безопасность приложения, поддержку и релизы своего интерфейса отвечает ваша команда.
    • Документированный API — основа архитектуры: один контракт работает для веб-, мобильного и встроенного сценария, а в перспективе — и для агента через MCP. Navixy MCP
    Путь телематики

    Headless — ступень между white label и Composable Telematics

    Телематика проходит путь от готового интерфейса через headless-архитектуру к composable-платформе — и дальше, к agent-ready инфраструктуре, где данными и логикой пользуются не только люди, но и AI-агенты. Headless — ступень, на которой бэкенд уже открыт через API, а интерфейс становится вашим полем для дифференциации.

    • White label и Headless — соседние, равноценные ступени: выбирайте готовый интерфейс там, где он окупается, и собственный — там, где интерфейс становится вашим преимуществом.
    • Headless уже дает вам собственный интерфейс на документированном бэкенде — шаг к Composable Telematics можно сделать отдельно, когда понадобится независимость данных и логики. Composable Telematics
    Как это устроено

    Прикладной слой соединяет ваш интерфейс с телематическим бэкендом

    Гарантирует телематический бэкенд

    Документированный API и стабильная схема данных — например, таблица raw_telematics_data.tracking_data_core в IoT Query.

    Схема данных
    Отвечает ваш интерфейс

    Прикладной слой вызывает операции и берет только нужные поля; браузер не подключается к бэкенду напрямую.

    Гарантирует телематический бэкенд

    Доступ на чтение телеметрии через PostgreSQL-совместимое подключение IoT Query.

    Настройка подключения
    Отвечает ваш интерфейс

    Идентификация пользователей, хранение секретов и лимиты запросов — на стороне вашего решения.

    Гарантирует телематический бэкенд

    Учетные данные подключения на каждый экземпляр — изоляция тенантов на уровне бэкенда.

    Отвечает ваш интерфейс

    Сопоставление пользователя с тенантом и ротацию ключей команда согласует с Navixy до запуска.

    Гарантирует телематический бэкенд

    Операционная логика в IoT Logic: прием данных, преобразования, действия и маршрутизация.

    Операции логики
    Отвечает ваш интерфейс

    Интерфейс, доступность, обработка ошибок и поддержка пользователей — ваша зона ответственности.

    Между интерфейсом и бэкендом работает прикладной слой вашей команды: он вызывает документированные операции, ведет бизнес-логику и держит учетные данные поставщика на сервере, а не в браузере.

    • Прикладной слой проверяет права доступа, учитывает контекст тенанта и кеширует запросы к бэкенду.
    • Журналы, идентификаторы запросов и проверки версий связывают слои — сбой можно диагностировать за минуты.

    Три операции, которые определяют вашу headless-архитектуру

    Каждая проверяется отдельно: чтение телеметрии, идентификация тенанта и жизненный цикл релизов.

    SQL к живым данным

    Настройка подключенияСхема данных
    01SELECT *
    02FROM raw_telematics_data.tracking_data_core
    03LIMIT 10;
    raw_business_dataraw_telematics_data
    tracking_data_core

    Документированный PostgreSQL-совместимый доступ к таблице raw_telematics_data.tracking_data_core — читаете нужные поля напрямую.

    Прикладная логика — прием данных, JEXL-преобразования и маршрутизация — это IoT Logic на прикладном слое, а не контракт бэкенда. Операции логики

      Смотреть документацию
      Перераспределение ответственности

      Вы получаете свой интерфейс — и ответственность за него

      Такой обмен окупается, когда интерфейс отличает ваш продукт на рынке, а команда готова эксплуатировать его: аутентификацию, релизы, инциденты, поддержку клиентов. Если различия в интерфейсе не создают заметной ценности для клиентов, white label остается быстрым и экономичным выбором — равноценным, а не запасным.

      • Ваша команда проектирует взаимодействие, отвечает за доступность, безопасность фронтенда, релизы и поддержку клиентов.
      • Владельцы бэкенда и приложения фиксируют аутентификацию, авторизацию, лимиты запросов, версионирование и порядок эскалации до запуска.
      • Один пользовательский сценарий проходит целиком — отказ в доступе, устаревшие данные, частичный сбой, изменение API на стороне поставщика: так проверяют границу ответственности, а не единичный удачный запрос.
      • White label остается быстрым и экономичным выбором, если собственный интерфейс не создает заметной ценности для клиента. white-label
      Границы бэкенда
      Ваша команда отвечает
      • Аутентификация пользователей портала и сессии
      • Отображение данных, доступность, обработка ошибок
      Платформа предоставляет
      • Документированный API телематического бэкенда
      • Учетные данные подключения на экземпляр
      Проверка на одном сценарии

      Пройдите один сценарий — от подключения до поддержки

      Так граница ответственности видна на практике, еще до первой строки интерфейса.

      1. 01Идентификация пользователя
      2. 02Подключение по документации
      3. 03Запрос к таблице данных
      4. 04Отображение и поддержка
      5. 05Мониторинг и изменения
      Смотреть документацию
      Вопросы об архитектуре

      Вопросы о Headless Telematics

      Что такое Headless Telematics?
      Это архитектурный подход, при котором бэкенд открыт через документированные API, а интерфейс поставщика необязателен. Функции телематического бэкенда доступны через документированные API, и команда строит собственный интерфейс поверх готового ядра. Трекер, камера, TCU или автомобиль без экрана — отдельная, аппаратная тема; к этому термину она не относится.
      Значит, каждая функция бэкенда доступна через API?
      Не автоматически. Состав доступных операций и прав отличается по продуктовой поверхности — проверяйте его по актуальной документации для каждого сценария, прежде чем проектировать интерфейс.
      Кто отвечает за безопасность в модели Headless Telematics?
      Ответственность разделена по границе бэкенда. Navixy отвечает за защиту телематического бэкенда в согласованных границах; ваша команда — за собственный интерфейс, сессии, интеграции и операционные процессы вокруг него.
      Когда лучше выбрать white label вместо Headless?
      Когда собственный интерфейс не создает заметной ценности для клиентов. Готовый интерфейс под вашим брендом запускается без фронтенд-разработки. White label и Headless — равноценные ступени: выбирайте по тому, где разница в интерфейсе действительно значима для рынка. white-label
      Должен ли браузер обращаться к телематическому API напрямую?
      Обычно надежнее — через прикладной слой, которым управляет ваша команда. Прикладной слой централизует авторизацию, контекст тенанта, секреты, лимиты запросов и обработку изменений на стороне поставщика — один раз, а не в каждом клиентском приложении отдельно.
      Как проверить headless-архитектуру перед запуском?
      Пройдите один реальный пользовательский сценарий целиком. Для сценария с чтением последних координат проверьте не только успешный запрос, но и отказ в доступе, устаревшие или отсутствующие данные, тайм-ауты, частичный сбой, изменение схемы и путь эскалации в поддержку. Настройка подключенияСхема данных
      Можно ли оставить готовый интерфейс как запасной вариант рядом с headless-решением?
      Да, если это допускают продукт и коммерческие условия. Headless Telematics делает интерфейс поставщика опцией, а не обязательным условием — совместимость конкретных готовых и собственных сценариев для вашего варианта развертывания уточните с Navixy отдельно. white-label
      Когда Headless Telematics начинает окупать себя?
      Когда бизнес-процесс, важный для клиента, оправдывает разработку собственного интерфейса. Срок зависит от готовности интерфейсов, проектирования идентификации и тенантов, разработки приложения, интеграционных тестов, проверки безопасности, наблюдаемости и объема миграции — единого срока для всех сценариев нет.
      Может ли AI-агент или инструмент разработчика работать с headless-бэкендом?
      Да, через тот же документированный доступ, что и обычная интеграция. Navixy публикует MCP для пользовательских и Admin Panel аккаунтов, а также публичный MCP по документации. Агент проходит ту же аутентификацию и работает в тех же границах доступа, что и любое приложение. Navixy MCP

      Постройте свой интерфейс на документированном бэкенде Navixy

      Начните с одного пользовательского сценария: определите нужные операции бэкенда, зоны ответственности и жизненный цикл — до того, как команда напишет первую строку интерфейса.

      Смотреть документацию Перейти к Composable Telematics

      Headless Telematics открывает бэкенд через API — состав операций для вашего сценария проверяйте по документации.