device-control-service: HTTP/JSON API (internal/httpapi) рядом с gRPC —
POST /devices/{id}/turn-on|turn-off|set-level, тот же server.Server внутри,
без дублирования логики. Решение вместо gRPC-клиента на PHP: grpc/grpc
через PECL компилируется в Alpine 10-20+ минут и утяжеляет образ, а
диаграмма архитектуры в ТЗ и так допускала HTTP для Laravel→device-control.
Laravel: DeviceShadow (чтение Device Shadow из Redis, MGET одним запросом
для списка устройств), ClickHouseClient (HTTP-интерфейс ClickHouse,
параметризованные {name:Type}-запросы), DeviceControlClient (HTTP-вызовы
к новому Go-эндпоинту). Redis-клиент — predis (чистый PHP), а не phpredis,
по той же причине, что и решение по gRPC — не добавлять ещё одну
C-компиляцию в образ.
DeviceController::show — страница устройства: live-статус/last_seen/
desired-reported state из Redis, история показаний из ClickHouse (для
сенсоров), кнопки ручного управления (для актуаторов, только owner,
с проверкой capability устройства). В devices/index — бейдж online/
offline/unknown. Дашборд дополнен счётчиком онлайн-устройств.
Два реальных бага найдены и исправлены при сквозной проверке:
1. Пустой action_params сериализовался в JSON-массив "[]" (PHP не
различает пустой список и пустой объект), а Go ждёт объект —
rule-engine-service падал на unmarshal. Фикс — JsonObjectCast
(JSON_FORCE_OBJECT) на AutomationRule::action_params.
2. Redis-ключи device shadow — общее пространство имён с Go-сервisами
(сырые ключи без префикса), а Laravel по умолчанию добавляет ко всем
ключам префикс "app-name-database-" — Laravel никогда не видел
реальные данные. Фикс — REDIS_PREFIX="" в окружении контейнера
(важно: пустое значение в docker-compose YAML нужно задавать явно
через "", просто "KEY:" означает "взять из окружения хоста").
Проверено сквозным тестом через docker compose: полный цикл телеметрия →
правило → команда воспроизведён вживую с реальным исправлением на лету;
ручное управление (turn_on/turn_off/set_level) из Laravel UI подтверждено
через браузер — HTTP-вызов к device-control-service, обновление
desired_state (merge-patch), реальная MQTT-команда поймана мониторингом
топика. 38/38 тестов Laravel, все Go-тесты device-control-service зелёные.
laravel-app (PHP/Laravel)
Статус: каркас реализован (авторизация, схема БД, модели). CRUD-интерфейсы и дашборд — в процессе.
Зона ответственности:
- Аутентификация и роли пользователей (Sanctum: сессии для Blade-UI + токены для будущего API/мобильного клиента), owner/viewer.
- Владеет схемой PostgreSQL (
database/migrations/*.php) — users, zones, device_types, devices, automation_rules. Go-сервисы читают/пишут эти же таблицы, но не управляют их структурой. - CRUD зон/устройств/правил автоматизации через веб-интерфейс.
- Просмотр истории телеметрии (запрос к ClickHouse) и текущего состояния устройств (чтение Device Shadow из Redis, который ведёт device-control-service).
- Ручная отправка команд устройствам — вызов device-control-service.
Не входит в зону ответственности: приём/хранение телеметрии, обработка правил в реальном времени, отправка MQTT-команд — это Go-сервисы. Laravel только читает их данные и вызывает device-control-service по gRPC/HTTP для управления.
Архитектурные решения
- Sanctum, а не просто сессии. Даже при том, что UI сейчас — Blade (Breeze), Sanctum используется с самого начала, чтобы токенная авторизация API была готова для будущего Vue/Flutter-клиента (этап 3) без повторной переделки авторизации.
- Роли и категории как PHP-enum, а не хардкод строк.
App\Enums\UserRole(owner/viewer),App\Enums\DeviceCategory(actuator/sensor),App\Enums\ConditionOperator(>,<,>=,<=,=,!=) — всё это закрытые, архитектурные множества значений.action_typeв правилах автоматизации намеренно остаётся обычной строкой, не enum'ом — это открытый, расширяемый список, управляемый данными вdevice_types.capabilities, а не кодом (иначе новый тип устройства с новой командой потребовал бы правки кода — что прямо противоречит идее платформы). - device_types — открытый реестр. Сидер (
DeviceTypeSeeder) заполняет типы устройств гроубокса (light, pump, fan, sensor_temp_humidity) как пример данных, а не как встроенную в код бизнес-логику. Добавление типа для другой зоны — просто новая строка.
Docker
Собирается в один контейнер (PHP-FPM + Nginx, управляются через supervisord)
— см. Dockerfile. Образ включает require-dev-зависимости (в частности
fakerphp/faker), так как сидер намеренно создаёт демо-аккаунт через
fake(); это MVP-образ с демо-данными, а не hardened prod-сборка.
Запуск
Локально (вне Docker), с уже поднятыми postgres/redis из корневого
docker-compose.yml:
cd laravel-app
composer install
cp .env.example .env && php artisan key:generate
php artisan migrate --seed
php artisan serve
Через Docker — сервис laravel-app в корневом docker-compose.yml,
конфигурация берётся из переменных окружения (секция Laravel app в
корневом .env.example).