❓ FAQ

Frequently Asked Questions

Why are the MessagingAgent and the backends two separate things?

The MessagingAgent should always be able to save messages locally and schedule them to be sent out. The code that creates the message should not wait until the message is sent out to continue its work. The MessagingAgent write the message to a local database, which only takes a fraction of a second. The backends pick up the messages from this local database and send them out when they can. This way, a connection issue with the backend or a long delay in sending out messages does not affect the rest of the system.

Additionally, the MessagingAgent is protocol-independent - it uses its own logic to communicate with the local message storage, but the backend connector can use any protocol to send out the queued messages.

Read about Semantic Versioning here (opens in a new tab).

How does the versioning of the Ivy Template repository work?

All versions 1.X will have the same architecture as version 1.0. Meaning, you can upgrade your own DAS-repository to non-breaking versions. Versions 1.X and following can add new backends, fix bugs and improve performance, expand the documentation, and so on - but they will not break your existing DAS-repository because the internal APIs will remain the same.

We are happy to accept feedback on the architecture itself though, which will lead to a new major version (2.X).

Is the Ivy Template complete?

Yes, it is usable and yes, we thought long about its architecture. The core architecture should hopefully cater to most use cases. However, we want to add everything to the template repository that could help most users: more backends, more documentation, better CI, better tests, more utility functions.

Hence, if you are using Ivy and think your developments could help others in developing their own DAS, we are happy to include your contributions and, of course, add you and your institution to the list of contributors.

Which backends do you see fit for the Ivy Template?

Since the MessagingAgent is independent of the protocol used to communicate with the backend, one can use HTTPS, LoRaWAN, CoAP, or any other protocol to communicate with the outside world.

We included ThingsBoard (opens in a new tab) and Tenta (opens in a new tab) for now, because these two are primarily designed for this type of workload. We are happy to include any backend that fits and does not require many additional dependencies.

Customizable Backends (CMSs)

The storing of messages, configurations and logs does actually not require that much logic when using HTTPS and could be achieved using Strapi (opens in a new tab), PocketBase (opens in a new tab), or Directus (opens in a new tab). However, all of these just mentioned platforms are not targeted at storing a large amount of time series data generated by a sensor network. Nevertheless, both Strapi (opens in a new tab) and Directus (opens in a new tab) can be self-hosted, are open-source and can connect to many database flavors (like PostgreSQL). Hence, we do not see an architectural reason why they should be less performant than dedicated IoT backends, besides storing more metadata than necessary and not having time-wise aggregation queries built-in. I would not recommend PocketBase (opens in a new tab) for this use case since it uses SQLite under the hood.

Databases

You could actually skip a backend altogether and make clients directly write into a database. PostgreSQL and other database flavors support Row Level Security (RLS) (read about it in the PostgreSQL docs (opens in a new tab)). Supabase has great documentation on this here (opens in a new tab). If you do want to use a pub-sub messaging system to your clients, one could use Node-RED (opens in a new tab) to pipe Kafka or MQTT traffic into a database.

Other IoT backends

The indicator of "readiness" is our personal judgment.

To be honest, I recommend using any backend that is not much work to set up and that does not lock you in.

Why is this template only compatible with python>=3.10?

Because the Python 3.10 release added many new ways of type hinting. We will not increase this minimum Python version in the near future, though.

🌳 OverviewFile System Layout