My user-base is largely going to want to connect their LoRaWAN data to cloud IoT infrastructure - namely AWS IoT Core, Pub/Sub and Azure IoT - rather than use the local MQTT broker. But I was hoping to use a single server on our end to handle this.
My hope was that the product would let me quickly and easily bridge an orgs data to a destination - and the HTTP endpoint does allow this, but it requires someone to get in there and fiddle with the plumbing.
Now this is a bigish change, but perhaps the ideal goal is to make the integration engine pluggable? Lets say that there was a folder of configuration files where you could register your own integration endpoints, and back-end services that handled all of the communication required (these services largely written by the community, not yourself).
Chirpstack would display HTML pages from the integration plugin to allow configuration - ie. setting the AWS IoT certificates - and would store JSON-encoded form results.
When the integration services restart or get an update signal (via the back-end broker), they call an API endpoint in Chirpstack. That API gives a list of configuration options (from the form) and the associated MQTT paths to listen to (ie. the MQTT path to the application).
Then those services mind their own business pushing data out to you-don’t-care-where - all your software really has to do is keep the services informed of the configuration and point-set.
This way you could get really crazy with integrations - they could be attached globally, to an org, to an application - you could even theoretically connect one to a device-type or gateway, although I’m not really sure there’d be any call for that.
They’d also be completely configurable from the web frontend, making a seamless-looking experience, but you and the rest of the Chirpstack devs wouldn’t have to worry about maintaining dozens of different integrations as part of the core product - you stick to your core set of message brokers and perhaps a couple of your most important integrations, but the community takes care of the rest.
If all comms are through an MQTT broker, you could even run these service endpoints on remote systems, allowing users to scale-up big distribution workloads (bring up multiple machines to distribute data to AWS), or vice-versa you could have a single AWS IoT integration service handling the traffic from multiple Chirpstack instances - pretty flexible.