I’ve started playing with InfluxDB and sending data to it via Zato. It’s easy enough to get something working with a plain HTTP channel or a service that pulls in the official client library.
I’m wondering if there’s any appetite for a new outgoing channel type that directly supports InfluxDB though? It would create a requirement for the InfluxDB Python library to be installed, but I’m thinking a service type with a GUI that gathers the parameters (URL, database, retention policy and credentials) and allows JSON or XML data posts that are then passed through the library.
You could have a separate connection for each database/retention policy combination and then be able to simply invoke it from any other service.
this sounds like an interesting idea!
Don’t worry about adding a new library - it is natural that if a new feature requires new dependencies then they are simply added, that’s the way it works.
As for the new Zato object - I understand that it would be a new type of an outgoing connection since it would allow one to fetch data on demand rather than to receive it on input?
Are you saying that it would be a wrapper around InfuxDB’s REST API?
Would that be a stateless or stateful type of connection, essentially are credentials passed into InfluxDB in each call or is there a notion of a session within which one issues queries?
Yes, it would be a new outgoing connection type to store the URL, database name and credentials, and the InfluxDB Retention Policy (so you’d create new outgoing connection for each database/RP combination).
Essentially it would be a wrapper around the InfluxDB client library, which in turn is a wrapper arounds the REST API. The cilent initialises a connection and can run multiple commands through it, but essentially the underlying API is stateless.
The main advantage of using the client library is that it takes a JSON body for writes and handles the serialisation to the InfluxDB format - so no need to rewrite that. For reads it just passes a select statement.
It’s been a long time, but I’ve revisited this and on reflection I think a service is sufficient. It doesn’t seem worth having an outgoing channel type - there are too many potential external systems, of which InfluxDB is only one.
Better to keep Zato lean and use services?
I’ve written up my method in a blog post