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.