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.

[vertebre]

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

mais mon serveur n'est rien de plus qu'un client de la bdd firebase, quand une donnée change dans firebase elle change pour le client également, idem pour le serveur qui lui l'enregistre en BDD perso. si j'ai une désynchronisation de données il n'y a pas de risques du moment que la BDD firebase est correct car je n'ai pas de contraintes temps réels sur ma bdd perso.

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

alors oui c'est intéressant de déporter la charge du calcul sur les clients, mais si je prend en compte la charge des requêtes nécessaires au calcul, le fait de les déporter coté serveur me permet de factoriser en une seule requête la demande de plusieurs clients souhaitant accéder à la même ressource dans un même laps de temps.
De plus, la méthode du calcul ne doit pas être connu du client, et son résultat doit être fiable(j'entend par là que le client ne doit pas pouvoir modifier la valeur de ce résultat avant envoie pour enregistrement), cela m'évite également tout un tas de vérification coté serveur sur le résultat que le client renverrait.
D'autre part, je suis sur une application mobile et soulager le client est important.

à propos de mettre en place le bloquage de la saisie

Grâce à vos réponses, notamment la solution de Watilin, j'ai pensé appliquer le timeout non pas sur les champs mais sur un bouton "sauvegarder les données". En ce sens, la saisie est toujours possible, l'appuie sur le bouton sauvegarder également mais l'enregistrement est gérer selon le délai et prend en charge la modification éventuelle des données après une première modification. Pour être claire sur ce que je compte mettre en place, la fonction updateData() proposé par Watilin est appliqué à mon bouton "sauvegarder les données" qui lui gère le timeout et le stockage intermédiaire des données des champs modifiées.


merci pour lu temps passé sur mon problème

bonne journée,


PS: j'apporte mon point de vue en me basant sur ma propre expérience si modeste soit elle, je n'essaie pas d'avoir raison bien qu'en me relisant je me dis qu'on pourrait le penser, il n'en ai rien. j'apprécie de débattre et bien sur de me faire critiquer.

[Spartacusply]

mais mon serveur n'est rien de plus qu'un client de la bdd firebase, quand une donnée change dans firebase elle change pour le client également

Je me permets d'intervenir pour argumenter en faveur de la thèse soutenue par Marco46. Si vraiment ton serveur n'est qu'un client pour firebase alors pourquoi celui-ci existe t-il ? Et inversement si tu as les données en locale, alors à quoi sert firebase ? Quoi qu'il arrive il y aura toujours une composante en trop, inutile, qui fait doublon.

Firebase devient trop cher, tu changes d'avis ? Pas grave, tu dump à ce moment là (et pas au runtime) l'ensemble des datas contenus sur firebase et tu repars avec une base locale.

Dupliquer des données entre des bases je l'ai fait. 1 fois. Pas 2. C'est ingérable et même avec la gestion la plus rigoureuse qui soit, y'a toujours à un moment où la synchro se passe pas bien et après bonjour la galère...