Voilà normalement l’historique paginé fonctionne avec jaklis:
Cependant j’ai du mal à voir de gain de temps en sélectionnant 1 ou 1000 transaction.
J’ai l’impression que charger tout l’historique d’un coup est plus long qu’avant, c’est le cas ?
Si tel est le cas ce n’est pas bien grave, dans un client lambda pas besoin de charger toute l’historique d’un coup tous les 4 matins.
Mais c’est peut être dû a mon implémentation en python.
Je vous dirais ce qu’il en est en Dart.
Normal 10, 100 ou 1000 éléments c’est du pareil au même car la majeure partie des traitements ne dépendent pas du nombre d’éléments, il te faut beaucoup plus d’éléments pour sentir une différence notable 
Je pense que ce n’est qu’une impression. Il y a des milliers de facteurs qui influence le temps de réponse d’un serveur. Pour pouvoir comparer il faut faire la même requête beaucoup de fois et dans les mêmes conditions réseau et dans les mêmes conditions de charge serveur. (donc de pref sur un serveur local).
Il y a autre chose: la différence entre 1 ou 1000 transactions ne viens pas tant du serveur que du client. Si le client à une mauvaise connexion internet (ce qui peut être souvent le cas sur mobile en déplacement), alors là la différence peut être significative
C’est pour cela qu’une pagination avec des pages de petite taille me semble indispensable sur mobile 
Oui tu as raison, on sens bien la différence entre 1000 et 10 transactions en fait:
Pour 1000:
$ while true; do time ./jaklis.py history -n1000 > /dev/null; sleep 0.1; done
real 0m2,745s
real 0m2,665s
real 0m2,753s
real 0m4,911s
real 0m2,186s
real 0m2,172s
real 0m2,116s
real 0m2,290s
real 0m2,058s
real 0m2,925s
real 0m2,760s
real 0m2,428s
Pour 10:
$ while true; do time ./jaklis.py history -n10 > /dev/null; sleep 0.1; done
real 0m0,557s
real 0m0,508s
real 0m0,508s
real 0m0,504s
real 0m0,498s
real 0m0,496s
real 0m0,500s
real 0m0,483s
real 0m0,493s
real 0m0,493s
real 0m0,501s
5x plus rapide pour un rapport de 1 à 100 !
Bon il me restera à gérer les pages suivantes/précédentes, mais je compte pas le faire en python.
Deux nouvelles requêtes et une nouvelle souscription dans GVA :
Il est désormais possible de recevoir les nouveaux blocs par websocket via les souscriptions newBlock et newBlockMeta :
newBlockMeta donne accès uniquement aux méta-données du bloc mais est mieux optimisée 
Donc désormais entre l’export json de la blockchain avec dex et la souscription GVA newBlock il est possible pour tout programme tiers d’accéder à l’intégralité de la blockchain et de mettre à jour ses données en temps réel, alors heureux ? 
Fourni les issuersFrame dernier blocs. Permet de faire des stats sur la fenêtre courante (comme la diff. perso. de chaque membre forgeron par exemple).
Il commence à y avoir pas mal de nouvelles requêtes et de souscriptions. Est-il possible d’avoir un document similaire à celui de BMA qui documente GVA. Je sais qu’il est possible de récupérer le schéma GVA directement via une requête. Mais documenter les choses c’est encore mieux et plus agréable à lire.
En fait la doc existe déjà elle est généré automatiquement et accessible via chaque noeud GVA:
Je la trouve très pratique, c’est grâce à ça que j’implémente GVA sans soucis.
Et au moins on est sûr qu’elle est à jours, à chaque nouvelle version de GVA, tu refresh la page et la doc est strictement à jour!
Edit:
Il y a même une zone de description custom qui je suppose est écrite par Elois, ici « Generate simple transaction document ». Je suppose que ces descriptions pourraient être plus explicites à l’avenir pour expliqué plus en détail à quoi peut servir la requête si ce n’est pas assez clair.
Perso je trouve les noms de queries et mutations choisis par Elois déjà assez clair intuitivement, mais si on veut chipoter, le top du top serait qu’en cliquant sur une queries dans la doc, cela pré-remplisse un exemple exhaustif dans graphql playground pour l’exécuter en un clique. Mais là c’est plus de l’ordre du luxe, je sais pas si graphql playground permet ça.
Je sais que d’autres outils permettent de le faire, comme ici.
C’est génial avec ces 3 souscriptions ya tout pour faire des widgets à changement d’état pour y afficher en temps réel l’arriver des nouvelles transactions en attentes, puis validés, le nombre de membre, le montant du DU ect ect … Et à moindre frais !
Pour simplifier l’utilisation de GVA j’ai fusionné les souscriptions newBlock et newBlockMeta. Le serveur choisi automatiquement la variante la plus optimisée en interne, donc utilisez newBlock dans tous les cas
Je ne vais pas développer de nouvelles fonctionnalités sur GVA pour le moment.
Je vais lancer une formation «comment contribuer à GVA» début Janvier 2021, je sais déjà que @tuxmain @vit @1000i100 et @HugoTrentesaux sont intéressés.
Je suis en train de découpler le plus possible le code de GVA du reste du cœur pour que les futurs contributeurs de GVA n’aient pas à se soucier du cœur
Mon but est de pouvoir me consacrer aux autres gros chantiers de Duniter et de laisser le développement de GVA à d’autres contributeurs. Je pense avoir implémenté suffisamment de fonctionnalités pour que les futurs contributeurs de GVA aient suffisamment d’exemples pour s’y retrouver.
D’accords,
Du coup je lance un appel à tout future contributeur de GVA, une requête qui me semble très utile et probablement pas très compliqué à implémenter (j’en sais rien en fait), serait de pouvoir récupérer le userID correspondant a une clé publique et inversement
En effet c’est simple et c’est précisément pour cela que je ne l’ai pas fait.
J’essaye volontairement de m’abstenir de faire les taches trop simples, car ce sont des 1eres taches idéales pour de nouveaux contributeurs
Dans les endpoints GVA publiés sur ton noeud, @elois, je vois un S (après le préfix GVA) dont je ne trouve pas de trace.
GVA S g1.librelois.fr 443 gva
GVASUB S g1.librelois.fr 443 gva-sub
Quel en est le sens ? Est-ce pour SSL ? Si oui, est-ce optionnel, ou bien y a t’il une autre lettre possible ?
Réponse message #14:
Tu peux proposer une autre convention, mais il faut que la couche TLS soit explicitée, afin que le client sache quel protocole il doit utiliser, sans avoir à faire d’hypothèse en fonction du port. L’API GVA n’étant pas réservée au monde du web
avec un espace devant en plus, donc ? C’est volontaire ?
Ca ne devrait pas etre GVAS plutot ?
Oui je trouve que c’est mieux décollé. Ça permet de séparer l’information relative à la nature de l’API de l’information relative à la couche de sécurité.
Je trouvais justement chiant et pas élégant avec BMA de devoir chercher les endpoint BMA et BMAS.
Si on travaille sur l’API T, ça me semble plus propre de pouvoir chercher tout les endpoint de type T, indépendamment du fait qu’il y est une couche TLS ou non.
ok ca me va. merci
Je viens de tester. Bravo c’est très rapide ! Cela promet de belles choses.
En revanche, je trouve étrange de devoir encapsuler le retour dans both, sent, etc. Ce n’est pas intuitif.
N’est pas plus simple, d’ajouter un paramètre optionnel à la requete (par exemple direction: all|sent|received) - all par défaut. Aussi, pour avoir un seul type d’objet de retour, pouvoir récupérer direction dans le retour.
Autre question, concernant la pagination : de ce que je comprends, il n’y a pas possibilité de trier comme on veut ? Ce sera toujours par block (=date) (et pas par montant, etc) ?
Dans le type de retour, n’est pas utile ajouter des fonctions d’aggrégation (sur chaque TX) ? Par exemple pour avoir le montant d’un TX ? En l’état actuel, je ne vois pas le gain par rapport à BMA (outre les performances) : le client devra parser les inputs/outputs pour afficher un montant.
Ou alors j’ai loupé un truc ?