Allow Existing API to to bridge with Pusher and allow preprocessing of payloads before transmission

user_5156141 0
Viewed 200

I’m currently working on bidirectional communication between some IoT sensors and a mobile app using Pusher channels.

I have been able to get Pusher working on the IoT nodes using the Arduino library and also in my React Native app.

However, I’ve hit a bit of a roadblock. My IoT sensors aren’t capable of producing JSON payloads and arrays (they broadcast batches of 30 readings at 30 second intervals) due to memory constraints. Each reading can be up to 60 characters in length unprocessed and a full payload being sent every 30s would be at least 1800 bytes, then there’s the header data (Auth token and session data for the sensor’s context).

I do not want to parse this hex data on my React Native app (as some comes from proprietary sensors where the protocol cannot be risked being divulged) so need it to happen on my ExpressJS API (currently handles the authentication and historic data retrieval) before it enters Pusher and pings the React Native app.

My questions:

  1. If the sensor made a POST request to my Express API in which the route performed the processing from hex into nice JSON (with full text values!) - can I use the Pusher client to get this data into the correct channel? Instead of having the sensor talk straight to Pusher?
  2. Is there a way to bridge the Pusher service through my API so that the React Native app “points” to my API for the updates instead of directly to Pusher?

Here is the architecture that I’m trying to achieve - hoping those of you who have experience with Pusher can tell me if this is possible: Architecture Diagram

I’ve seen the “pusher-http-node” server library but there’s no tangible description of why this would be used.

Really hoping I don’t need to go down the MQTT route and have my own micro service (something I’ve wanted to avoid given the costs and scalability concerns).

pusher-js pusher iot express
1 Answers

DevRel at Pusher here.

To answer your questions:

  1. That setup makes sense. Your Express API can preprocess each sensor event before sending them to the Channels service - you'd use the Node SDK on the server. That preprocessing can include putting it in the correct format, and sending to the correct channel.

For the difference between SDKs:

The pusher-http-node SDK is designed to run on servers, and can send messages to any channels you want. It also holds your private keys - something that your React Native client SDK doesn't. Server SDK doesn't implement subscriptions.

The pusher-js client SDK that you use in the React Native apps on the other hand can only subscribe or send client events.

  1. Your client applications should connect to Pusher Channels service so they can receive realtime updates. Channels serves as the transport here. Your Express API should use pusher-http-node to send these events to Pusher Channels.

So, to summarise:

  • Have your IOT sensors communicate raw data to your Express API
  • In your Express API do the preprocessing of these raw events, turning them into something your React Native apps can understand and use
  • In your Express API use the pusher-http-node library (server SDK) to send these processed events to Pusher Channels service
  • In your React Native apps use the pusher-js library (client SDK) to connect to Channels service and subscribe to the events your Express API is sending.

I hope this clarifies it a bit!

user_6435160
Related