1. #1
    Membre régulier Avatar de vertebre
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2015
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2015
    Messages : 184
    Points : 108
    Points
    108

    Par défaut listenners sur changements de valeurs + déclencher calcul d'un résultat

    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

  2. #2
    Expert confirmé Avatar de Watilin
    Homme Profil pro
    En recherche d'emploi
    Inscrit en
    juin 2010
    Messages
    2 214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : En recherche d'emploi

    Informations forums :
    Inscription : juin 2010
    Messages : 2 214
    Points : 4 318
    Points
    4 318

    Par défaut

    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.
    La FAQ JavaScript – Les cours JavaScript
    Access42, ressources francophones sur l’accessibilité
    La touche F12 : l’outil indispensable à tout développeur JavaScript !

  3. #3
    Membre régulier Avatar de vertebre
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2015
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2015
    Messages : 184
    Points : 108
    Points
    108

    Par défaut

    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 ?

  4. #4
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 717
    Points : 8 338
    Points
    8 338

    Par défaut

    Citation Envoyé par vertebre Voir le message
    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.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  5. #5
    Membre régulier Avatar de vertebre
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2015
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2015
    Messages : 184
    Points : 108
    Points
    108

    Par défaut

    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,

  6. #6
    Expert confirmé Avatar de Watilin
    Homme Profil pro
    En recherche d'emploi
    Inscrit en
    juin 2010
    Messages
    2 214
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : En recherche d'emploi

    Informations forums :
    Inscription : juin 2010
    Messages : 2 214
    Points : 4 318
    Points
    4 318

    Par défaut

    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.
    La FAQ JavaScript – Les cours JavaScript
    Access42, ressources francophones sur l’accessibilité
    La touche F12 : l’outil indispensable à tout développeur JavaScript !

  7. #7
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 717
    Points : 8 338
    Points
    8 338

    Par défaut

    Citation Envoyé par vertebre Voir le message
    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.

    Citation Envoyé par vertebre Voir le message
    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.

    Citation Envoyé par vertebre Voir le message
    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.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  8. #8
    Membre régulier Avatar de vertebre
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2015
    Messages
    184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2015
    Messages : 184
    Points : 108
    Points
    108

    Par défaut

    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.

Discussions similaires

  1. [VB.NET]Test sur changement de valeur d'une variable
    Par shinji_rem dans le forum Windows Forms
    Réponses: 9
    Dernier message: 29/11/2006, 16h53
  2. Evénement sur changement de valeur
    Par Hypollite76 dans le forum Delphi
    Réponses: 5
    Dernier message: 22/11/2006, 17h08
  3. submit form sur changement de valeur
    Par killerhertz dans le forum ASP
    Réponses: 4
    Dernier message: 23/07/2006, 16h05
  4. [VBA-E]Lancer une macro sur changement de valeur cellule ?
    Par jeremiegrenoble dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 07/03/2006, 15h22
  5. Réponses: 1
    Dernier message: 29/09/2005, 12h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo