Goal
I'm currently building a web-application to control multiple IOT devices over the cellular network, given the nature of the devices (working off battery power and operating in network constrained environments) I have chosen HiveMQ as the means to facilitate communication, this is a message broker which implements the MQTT protocol. I need to maintain a constant stream of telemetry updates from each device which are displayed in the web-app to the user in real-time. In addition I need to be able to send a command to a device and receive a response from the device as to whether it has successfully started (not completed) performing the issued command. If the device cannot perform the task for some reason it sends back an error code which the user will be notified of in the web-app.
Current Prototype
I have built a prototype (which currently only works with a single IOT device) using a NodeJS back-end by using a MQTT client and socket-io (web-sockets).
I understand its not the convention to see request/ response over a pub/ sub mechanism, however the MQTTv5 spec supports a request/ response pattern and MQTT plays nicely with constrained devices. Honestly I'm not really aware of what a suitable substitute for MQTT would be for this project. Also note I discarded the idea of a 'MQTT over web-sockets' client library (ie: Paho mqttws) as it exposed to much information about the MQTT broker.
Scaling the design
I'm now extending my prototype towards supporting multiple IOT devices, my thinking is to continue using MQTT client -> web-socket to receive real-time telemetry updates and to use a REST API to issue commands to devices. HiveMQ provides an extension frame-work in which I intend to build the REST API as an extension on the MQTT broker.
Future Problem to consider
Lastly, as I continue to extend this project I will need to find a way to handle the event in which two users each try to send a command to a device at the same time. My sense is that using a REST API makes this issue easier to solve as there is a central point in which I can handle / block a second command being issued at the REST API and can avoid the message being pushed to the MQTT broker.
Question
Does what I have described seem to be a reasonable design given the requirements I have outlined or is there a better approach?
I'm wondering if there is a better way to accomplish this as this design feels slightly unconventional. Any feedback greatly appreciated.