Разрешить существующему API связываться с Pusher и разрешить предварительную обработку полезных данных перед передачей - PullRequest
0 голосов
/ 12 января 2019

В настоящее время я работаю над двунаправленной связью между некоторыми датчиками IoT и мобильным приложением, используя каналы Pusher.

Мне удалось заставить Пушера работать на узлах IoT с помощью библиотеки Arduino, а также в моем приложении React Native.

Тем не менее, я столкнулся с некоторым препятствием. Мои датчики IoT не способны генерировать полезные нагрузки и массивы JSON (они передают пакеты по 30 показаний с интервалом в 30 секунд) из-за ограничений памяти. Каждое чтение может иметь длину до 60 символов в необработанном виде, а полная полезная нагрузка, отправляемая каждые 30 секунд, будет не менее 1800 байт, а затем есть данные заголовка (токен аутентификации и данные сеанса для контекста датчика).

Я не хочу анализировать эти шестнадцатеричные данные в моем приложении React Native (поскольку некоторые из них поступают от проприетарных датчиков, где протокол не может быть разглашен), поэтому необходимо, чтобы это происходило в моем API ExpressJS (в настоящее время обрабатывает аутентификацию и исторические данные до входит в Pusher и проверяет связь с приложением React Native.

Мои вопросы:

  1. Если сенсор отправил POST-запрос в мой Express API, в котором маршрут выполнял обработку из шестнадцатеричного в хороший JSON (с полнотекстовыми значениями!) - могу ли я использовать клиент Pusher для передачи этих данных в правильный канал? Вместо того, чтобы датчик говорил прямо с Пушером?
  2. Есть ли способ связать службу Pusher через мой API, чтобы приложение React Native «указывало» на мой API за обновления, а не прямо на Pusher?

Вот архитектура, которую я пытаюсь создать - надеясь, что те из вас, кто имеет опыт работы с Pusher, могут сказать мне, если это возможно: Architecture Diagram

Я видел серверную библиотеку «pusher-http-node», но нет четкого описания того, почему это будет использоваться.

Действительно надеюсь, что мне не нужно идти по маршруту MQTT и иметь свой собственный микро-сервис (чего я хотел избежать, учитывая проблемы с расходами и масштабируемостью).

1 Ответ

0 голосов
/ 13 января 2019

DevRel на Pusher здесь.

Чтобы ответить на ваши вопросы:

  1. Эта настройка имеет смысл. Ваш Express API может предварительно обработать каждое событие датчика перед его отправкой в ​​службу каналов - вы должны использовать Node SDK на сервере. Эта предварительная обработка может включать в себя установку в правильном формате и отправку на правильный канал.

Для разницы между SDK:

SDK pusher-http-node предназначен для работы на серверах и может отправлять сообщения на любые каналы, которые вы хотите. Он также содержит ваши личные ключи - то, что ваш React Родной клиент SDK не делает. Сервер SDK не реализует подписки.

Клиентский SDK pusher-js, который вы используете в приложениях React Native, с другой стороны, может только подписывать или отправлять клиентские события.

  1. Ваши клиентские приложения должны подключаться к услуге Pusher Channels, чтобы они могли получать обновления в реальном времени. Каналы здесь служат транспортом. Ваш Express API должен использовать pusher-http-node для отправки этих событий на каналы Pusher.

Итак, подведем итог:

  • Ваши IOT-датчики передают необработанные данные на ваш Express API
  • В вашем Express API выполните предварительную обработку этих необработанных событий, превратив их в то, что ваши приложения React Native могут понять и использовать
  • В вашем Express API используйте библиотеку pusher-http-node (серверный SDK) для отправки этих обработанных событий в службу Pusher Channels
  • В ваших приложениях React Native используйте библиотеку pusher-js (клиентский SDK) для подключения к службе каналов и подписки на события, отправляемые вашим Express API.

Надеюсь, это немного прояснит!

...