Je ne connais pas du tout le domaine, donc j'ai du mal à voir combien de capteurs et combien de mesures sont nécessaires, donc c'est difficile d'en dire plus. Mais du coup si je comprends bien, à terme il s'agit de piloter aussi l'installation?
Je n'avais pas répondu sur la partie asynchrone. Django 3 est asynchrone (à terme Django channels et Django vont fusionner). Mais cette partie asynchrone n'est pas utile pour sauver les données dans une base (l'opération est par définition synchrone et bloquée par Django), ni pour faire des calculs très légers, ni pour les envoyer sur le frontend. Par contre si tu veux commencer à utiliser des algorithmes lourds pour analyser les données, je découplerai cette partie calcul du serveur de données.
Et s'il y a vraiment de gros flux de données à gérer et des gros calculs à faire, des solutions plus lourdes sont nécessaires (du genre Apache Kafka, Spark ou équivalent avec du Spring Cloud Stream pour lier le tout).
[^] # Re: pour l'asynchrone
Posté par Destop . En réponse au journal appli web cooperative viticole. Évalué à 1.
Je ne connais pas du tout le domaine, donc j'ai du mal à voir combien de capteurs et combien de mesures sont nécessaires, donc c'est difficile d'en dire plus. Mais du coup si je comprends bien, à terme il s'agit de piloter aussi l'installation?
Je n'avais pas répondu sur la partie asynchrone. Django 3 est asynchrone (à terme Django channels et Django vont fusionner). Mais cette partie asynchrone n'est pas utile pour sauver les données dans une base (l'opération est par définition synchrone et bloquée par Django), ni pour faire des calculs très légers, ni pour les envoyer sur le frontend. Par contre si tu veux commencer à utiliser des algorithmes lourds pour analyser les données, je découplerai cette partie calcul du serveur de données.
Et s'il y a vraiment de gros flux de données à gérer et des gros calculs à faire, des solutions plus lourdes sont nécessaires (du genre Apache Kafka, Spark ou équivalent avec du Spring Cloud Stream pour lier le tout).