I’m working on a IoT application where a web ui will need to:
display IoT devices and update in real time
display/edit users, organizations, and roles
Most of the work will be going into the devices display, but users, orgs, roles are needed for access control.
Initially I’m going down the SPA route, contrary to the many warnings against them on the net.
There can eventually be 1000’s of devices, so will need some way to synchronize information on a subset of them to the frontend.
I used meteor with a react frontent for my last project – worked well.
On this project I’m hoping to use a Go backend and Elm frontend.
Does anyone have suggestions on how to manage the data synchronization between the backend and elm? Meteor did that nicely – a change in the database automatically resulted in a change in data (they call it minimongo) in the frontend, and then the relevant frontend pieces got re-rendered.
Is GraphQl a good solution for this problem?
Appreciate any tips from those who have done this, or if I should just go back to a classic architecture with server rendered pages or Meteor.
I really like the benefits of Elm/SPA – provides a path to creating a PWA version, easier to display information that is continuously updating (think dashboard), nice SVG/graphics packages, etc.
Last company I worked for did IoT devices and used web sockets (technically AWS IoT library which layered MQTT on top of web sockets). Web sockets work really well with Elm, you’ll just need to hook them up though a couple ports.
Another option if you need to push data from the server to the client is Server Sent Events. With SSE you would lose support for IE and non-Chromium Edge.
@wolfadex – thanks for the input – I agree, I’ve used websockets some with elm and they do work well. Ports and websockets fit well together.
The more I think about graphql, the more I’m liking that approach. Graphql subscriptions would be handled using websockets:
Graphql would allow the server to construct the data (perhaps combined from multiple collections or tables) needed by the frontend without needing to synchronize a mini-copy of the database on the frontend and put things back together (E.g. minimongo). Maybe this is overcomplicating things, but it seems like a very flexible approach.
Interesting - Is this websockets and MQTT layer part of the AWS javascript library that sits on top of their IOT services? If they support websockets, I think they must have something that sits at the server end of that?
At the moment, I am working on generating Elm HTTP stubs for AWS services and tackling the REST-JSON ones. This will cover all the AWS IOT services - but not over web sockets, just the ability to call their HTTP interfaces. I guess that may still be useful though for the configuration etc. if not for the data streaming part?
@rupert I’ve been loosely following your work to see if I could use it when I was still at that company. We were in the middle of a of rewrite into Elm for the IoT devices.
They are using the AWS JavaScript libraries. IIRC they use aws, aws-sdk, and aws-iot-device.
I would use a library on the client like mqtt-js. That way you do not even need a server to stream sensor-data… Except for a Mqtt broker ofcourse… Simply subscribe/unsubscribe the information on the client. This way you also do not need to think about websockets directly.
You would probably have a server anyway for doing validations++ but that could also communicate over mqtt… think of the server as your update function in elm… looking at mqtt-messages coming from the clients and responding with new mqtt-events for the subscribed clients.