Has anyone successfully run nats.io in Ignition (as an alternative to MQTT)?
I see that their python 2.7 example on github requires the tornado package (4.2 - 6.0), which wraps asyncio. Not sure if anyone has experience trying to do this kind of stuff within the Jython constraints?
Any tips are appreciated.
I donât know what this is, but I already hate it, because I canât figure out WTF it is or does from the landing page. If you hadnât provided the MQTT clue Iâd be lost 
Lol! So true.
My (potentially wrong) understanding is that itâs just cloud-based pub/sub that supports a very high message throughput with a built in Prometheus/Grafana dashboard.
Youâre not going to have a fun time adapting any of the Python SDKs; even if you can get them to run, theyâre probably going to be catastrophically slower than they should through the Jython environment.
If you really wanted to pursue this, the ârightâ way would be a full custom module that brings in their Java SDK. Thatâs a large engineering task, though.
Yeah thatâs a good point. Ugh. Jython 
OK, may I take a step back then:
Ignitionâs built-in historian doesnât provide a way to attach context to a record (like a batch ID). I could use the built-in historian and use table joins and timestamp comparisons, but to me thatâs worse than the Java module.
Is there a best practice for storing âcontextualizedâ timeseries data? My current best guess is: a script that reads the tags, gets the context, and sends an MQTT message to a custom store.
SQL Bridge and Transaction Groups
Outside of that without the need to purchase another module, I would revert to Named Queries and a Gateway Scheduled Event or Timer Event
Thanks @lrose â Iâve taken this approach before. And it definitely works.
But currently I need to connect multiple factories to the same cloud-based data store. So my thinking is that if I put everything in a site-specific databases, Iâve just punted my problem further down the road. And if itâs a global database, Iâm likely to exceed the write limits.
Have a small update in this for any future readers. Nats.io supports MQTT, so the best thing might be to point the MQTT client towards a Nats.io server with MQTT enabled.
Been a few years since this post but wanted to mention that we tired to use MQTT NATS bridge as a solution but we have a very large throughput of data and were seeing issues with processing the stream over MQTT (latency issues), along with NATS labeling the client as a slow consumer terminating the connection so I started to switch over to use their native java library, first time doing any type of module dev so still working out a few bugs 
however results look promising so far!
My module uses a ManagedTagProvider to write new values to a tag based on the subject path as new messages are consumed. If you start having issues with the MQTT implementation might be good idea to look at the java client library instead of python 2.7
