Discussion :

[vertebre]

bonjour,

J'ai des listenners pour écouter le changement de valeur modifiées par le client.
Avec ces valeurs j'exécute un calcul, pas très compliqué en soit (le calcul) mais je ne sais pas quel est le meilleur moment pour le déclencher.

Pour illustrer le problème :

• Application cliente

-Les données utilisateurs sont : nom, prénom, age, sexe, mail, photo, site web, valeur, valeur2, valeur3, valeur(n)
-L'utilisateur modifie ses données
-L'application enregistre ses données en BDD indépendamment pour chaque donnée modifiée

• Application serveur

-L'application serveur est notifiée pour chaque changement de données détectés en BDD.
-L'application serveur doit alors lancer une fonction de calcul dont le résultat est directement impactée par la nouvelle valeur de chaque donnée modifiée
-L'application serveur doit renvoyer au client le résultat le plus tôt possible

• Question du problème :

Quand et comment envisage t on de lançer la fonction de calcul sachant que le client peut modifier, et re-modifier encore et encore ces données ?


bonne journée et merci de vos réponses

[Watilin]

Bonjour,
j’ai l’impression que tu ne sais pas exactement où se trouve la BDD. À moins que tu n’aies effectivement mis en œuvre un stockage côté client (ce qui est assez rare), la BDD se situe côté serveur.
Et le fait que tu fasses cette confusion me laisse penser que tu utilises un framework de databinding. Je me trompe ?

Le serveur n’a pas besoin d’être « notifié » d’un changement de données, car c’est le serveur lui-même qui effectue ces changements. Ton framework te fait croire que tout se passe côté client, mais en réalité il fait des appels au serveur.

Commence par nous dire les technos que tu utilises (langages client & serveur, frameworks, autres détails que tu juges utiles), parce que là tu n’as donné aucune info qui nous permette de t’aider efficacement.

[vertebre]

la BDD se situe côté serveur.

on est d'accord sur ce point, a quel niveau peux tu penser que je sous entend le contraire ?

Le serveur n’a pas besoin d’être « notifié » d’un changement de données, car c’est le serveur lui-même qui effectue ces changements. Ton framework te fait croire que tout se passe côté client, mais en réalité il fait des appels au serveur.

J'utilise firebase et l'application cliente intéragit avec les serveurs firebase de google qui les enregistre, j'ai également un application sur un serveur perso avec une BDD perso qui enregistre des données issues de la BDD firebase.

En gros: application cliente > firebase > mon application serveur est notifié des changements > récupération des changements depuis firebase > enregistrement en BDD perso

est ce plus claire ?

[Marco46]

En gros: application cliente > firebase > mon application serveur est notifié des changements > récupération des changements depuis firebase > enregistrement en BDD perso

est ce plus claire ?

Oui c'est quand même plus simple pour parler stratégie d'avoir une carte ...

Dupliquer les data dans deux DB différentes c'est une (très) mauvaise pratique. Y-a-t-il des raisons légitimes à une telle architecture ? Si oui lesquelles ?

Pour le reste, le calcul peut-il être implémenté côté client ? Formulé autrement, y-a-t-il des raisons légitimes à exécuter les calculs côté serveur ? Si oui lesquels ?

En bout de ligne tu es sur le web, tu es donc dans un contexte asynchrone et stateless. Il n'y a donc pas de solution parfaite à ton problème puisqu'il est inhérent à la nature du web, soit tu bloques la saisie tant que tu n'as pas reçu la réponse au dernier calcul soit tu considères que le dernier à raison (gaffe aux ordres de retour de tes requêtes, il te faut absolument une lib de type RxJS pour gérer l'ordonnancement des résultats). Généralement on ajoute une notion de "debounce" pour limiter le nombre d'exécution par de seconde.

[vertebre]

Dupliquer les data dans deux DB différentes c'est une (très) mauvaise pratique. Y-a-t-il des raisons légitimes à une telle architecture ? Si oui lesquelles ?

eh bien pour avoir une sauvegarde des données et une possibilité future de m'affranchir de firebase qui fonctionne gratuitement selon un système de quota.

le calcul peut-il être implémenté côté client ? Formulé autrement, y-a-t-il des raisons légitimes à exécuter les calculs côté serveur ? Si oui lesquels ?

eh bien non car les données nécessaires aux calculs sont : les données que le client vient de changer(20% des données) et du reste des données qui ont été modifiées et enregistrées il y a longtemps(80% des données) dans firebase. Le but de calculer coté serveur est de soulager le client également, et de garder une part de mystère dans ce calcul

tu bloques la saisie tant que tu n'as pas reçu la réponse

je vais essayer d'appliquer le principe, et noter les problèmes ou incohérences que çà me provoquent coté client.

merci pour cette réponse,

[Watilin]

D’un point de vue ergonomie, ça ne me paraît pas une bonne idée de bloquer la saisie.
Je pencherais plus pour un client qui laisse l’utilisatrice ou l’utilisateur faire sa saisie en toutes circonstances, mais qui dialogue en parallèle avec le serveur et informe l’humain quand une nouvelle version de la donnée est présente.

Pour répondre à ta question initiale, tu peux « délayer » (le terme anglophone est throttle) les mises à jour côté client en utilisant ce genre de conception :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const THROTTLE_DELAY = 400; // ms
 
function updateData(data) {
  // envoyer les infos au serveur
  // ...
}
 
let throttleTimer;
monInput.addEventListener("keyup", function (event) {
  clearTimeout(throttleTimer);
  throttleTimer = setTimeout(function () {
    updateData(event.target.value);
  }, THROTTLE_DELAY);
});

Le principe : quand l’utilisateur·trice fait une saisie, on marque une pause avec setTimeout avant d’envoyer les données. Si l’utilisateur·trice reprend la saisie avant la fin du délai, on réinitialise le timer et ça annule l’envoi des données.

L’exemple que je donne ici est basé sur l’évènement keyup et le délai est inférieur à une seconde. Mais si plusieurs inputs sont en jeu, il sera peut-être plus adapté de préférer change et d’augmenter le délai à une ou plusieurs secondes.

[Marco46]

eh bien pour avoir une sauvegarde des données et une possibilité future de m'affranchir de firebase qui fonctionne gratuitement selon un système de quota.

C'est une solution horrible d'un point de vue archi. Si tu veux une sauvegarde de données tu mets en place une sauvegarde données. Là tu ne sauvegarde pas des données tu les dupliques au runtime, c'est complètement différent.

Donc soit tu reste sur firebase et tu scratches ta db soit tu passe sur ta db et tu sors de firebase. Mais là tu es sur la pire des solutions, le risque étant d'avoir des désynchronisations de données entre tes 2 BDD, et là bon courage pour les gérer. C'est insoluble.

eh bien non car les données nécessaires aux calculs sont : les données que le client vient de changer(20% des données) et du reste des données qui ont été modifiées et enregistrées il y a longtemps(80% des données) dans firebase. Le but de calculer coté serveur est de soulager le client également, et de garder une part de mystère dans ce calcul

Le but de calculer chez le client c'est de soulager le serveur

Soulager le client n'a pas de sens (sauf si ton calcul est vraiment très long ou vraiment secret), tu as autant de client que de ... client. Tu n'auras jamais qu'un seul serveur pour tous tes clients (je rentre pas dans les détails de loadbalancing mais tu vois l'idée).

Calculer côté client c'est prendre la charge du calcul côté serveur, et la répartir sur tous les clients. C'est nettement plus intéressant.

je vais essayer d'appliquer le principe, et noter les problèmes ou incohérences que çà me provoquent coté client.

Comme le dit Watitlin en terme d'ergo c'est la pire des solutions. Du fait de la latence et du temps de calcul côté serveur ça risque de bien dégrader l'UX.