Questions GraphQL et la RFC pour l'APi GVA

Merci c’est corrigé :slight_smile:

Non, le terme court d’origine était blockstamp car c’est le terme qu’on utilise coté serveur blockchain pour désigné le couple (blockNumber, blockHash). Si je l’ai modifié c’est uniquement pour que son titre soit explicite en vue d son contenu.
BlockId ce n’est pas explicite, c’est même très ambigu car selon le contexte le BlockId peut etre seulement le numéro du bloc ou le numéro + le hash.

Si c’est un besoin il vaut mieux faire un champ différent, car cela suit une logique différent :
→ le blockcstamp c’est dans le document ça fait parti de l’entité requetée.
→ le reste du block c’est une entité a part qu’il faut aller chercher.

Perso, je trouve blocknumberandhash très laid, et je préfère largement blockstamp, quitte à avoir un petit glossaire quelque part.

Blockstamp est explicite une fois que tu sais ce qu’il signifie. Mais en plus il est court et allégé à la lecture.

4 Likes

Tout a fait d’accord ! :slight_smile:

Oui, je le sais bien. Mais peu de clients ne voudront pas l’avoir, le bloc.
Par ailleurs, le “contexte” de la requête graphql permet de savoir si l’entité est demandée par le client, afin d’aller le bloc uniquement quand cela est necessaire.
C’est d’ailleurs ce qui fait la force du graphql, vis a vis des autres API d’accès aux données, a min avis.

Salut à tous,
je bosse ces jours-ci sur GVA, pour Cesium² avec « GVA inside » :).
Du coup, je voulais vous demander de rendre ce sujet public, si possible. les discussions sont techniques, et fortes utiles pour avancer sur GVA;

Mes travaux sur GVA

évolution de la RFC

Je vais commencé des commits dans la RFC. Il manque par exemple l’accès au pramètres de la BC (/bockchain/parameters dans BMA)

évolution de GVA-API (module Duniter)

Je vais faire des commits dans le module Duniter gva-api.

@cgeek, pourras tu regarder mes commit sur gva-api de temps en temps, histoire que je ne fasse pas trop de bétises ? :slight_smile:
Pour la pagination, peux tu m’aider un peu, par exemple avec un exemple d’implémentation (par exemple sur les transactions). Comme ca touche au code SQL, je ne suis pas sur de la porter de ces modifications. Faut il que je touche au code de Duniter ?

Socle technique de Cesium²

Une version minimaliste va bientot être publiée (code ici), avec juste l’accès à l’annuaire.

Je tente une double implémentation BMA/GVA (en fonction du nœud choisi dans les paramètres), afin de rester compatible avec les nœuds existant en BMA.

C’est une sorte de POC du socle technique.
Pour ceux qui veulent/peuvent regarder : c’est le bon moment pour donner votre avis, histoire d’avoir du code clair…

  • node 10 (pour la compilation)
  • Angular 7
  • Ionic 4
  • Lib GraphQL : Apollo

a++

5 Likes

Voici ma première merge request sur gva-api :slight_smile: Si @cgeek est ok, je ferai les suivantes directement sur le repo.

1 Like

Aussi d’accord pour publier cette discussion.

2 Likes

5 messages ont été scindés en un nouveau sujet : RFC GVA > movementsByPubkey() et time redressé

Dernière question :slight_smile:

  • @elois, @vit avez vous commencez l’implémentation de GVA ?
    Si non, puis-je faire des modif directement sur la branche de la RFC, ou bien dois-je faire une MR vers cette branche ?

Pour ma part, pas d’implémentation en dur pour l’instant (pas de classes avec les query transposées en python). Seulement des tests de connection, de récupération récursive du schéma. Il faut faire les query à la main en GraphQL. donc je m’adapte à ce qui sera en place.

Donc pour la RFC je laisse la main, n’ayant pas le temps de m’en occuper. Je vous fais confiance.
Voir plutôt avec @elois qui a démarré une implémentation serveur.

Je commencerai à critiquer la RFC quand j’en aurai besoin pour Sakia, donc pas avant 2020… :wink:

Désolé de mon absence dans ce fil, mais au final je suis content que vous ayez réfléchi et pris les décisions sans moi :slight_smile:

Et puis je n’ai pas grand-chose à redire :

Ce schéma n’était qu’un POC pour le Cesium v2 de @kimamila, vous pouvez l’oublier. Je suis d’accord avec vous sur le principe de spécifier un maximum avant d’implémenter quand c’est possible, c’est un luxe que je n’ai pas eu pour BMA. Cela n’empêche toutefois pas la réalisation de POC pour ceux qui le veulent, c’est ce que j’ai fait. Cela permettent aussi de révéler des problématiques légèrement en amont de l’implémentation.

Mais bref, ce n’était vraiment pas une spécification ce schéma :slight_smile:

Je suppose que c’est une phrase raccourci car GVA n’est pas obligatoire pour une implémentation de Duniter (= DUBP) vu que c’est de niveau réseau (= DUNP). Il existera certes une implémentation GVA pour Duniter et Durs, mais pas sûr que ça intéresse Junidev ou d’autres développeurs de nœuds.

Aussi pour Duniter il s’agit d’un module externe. D’ailleurs ce module va peut-être exploiter sa propre BDD dédiée, adaptée aux contraintes de critères de recherche de l’API GVA. Ce serait bien car cela me forcerait à formaliser l’API interne de Duniter pour les événements liés à la blockchain.

Oui optionnelle en argument, mais obligatoire en réponse pour indiquer au client « Vous êtes ici ». Aussi, les valeurs maximales autorisées par l’implémentation devraient figurer dans ce même objet de réponse de pagination. Comme ça le client peut s’adapter et éviter de balancer des requêtes qui seraient rejetées. Ainsi, chaque implémentation peut poser ses conditions. :+1:

Peut-être d’ailleurs que l’API GVA pourrait prévoir une méthode de négociation, qui retournerait une fois pour toutes ces valeurs de plages acceptées en fonction de la requête, et donner la possibilité de ne plus recevoir à nouveau ces valeurs en réponse paginée (pour éviter de recevoir un champ devenu inutile).

Yes !

Je préférerais que tu n’y touches pas, ce n’est pas ton rôle, à la place je devrais plutôt développer plus clairement l’API interne de Duniter de sorte que l’on puisse exploiter plus spécifiquement ce besoin. Ou alors que je développe cette base de donnée spécifique GVA. Et je crois que cette idée me séduit davantage.

Super :slight_smile: si ça te va j’aimerais qu’on refasse une Cesium : tu reprends les droits de commit sur le dépôt et moi je peux intervenir en soutien. Donc tu fais ce que tu veux :slight_smile:

J’aimerais quand même vraiment développer cette BDD dédiée à l’indexation, ça me semble être le moins invasif pour le code du cœur et le plus simple pour toi d’exploiter les données qui t’intéressent.

2 Likes

Oui tout a fait, ça correspond au bloc fonctionnel que j’ai nommé “client indexer” dans ma présentation des rml13, ce bloc fonctionnel doit évidemment avoir sa propre bdd, tout ça pour dire que j’ai pris la même décision coté Durs :slight_smile:

2 Likes

Salut @cgeek,
J’espère que tu vas bien.

Je me demandais si on pouvais avancer sur un POC de BDD (ou API d’accès aux index) dédiée a GVA, d’ici les RML14 ?
Cela permettrait d’avoir un socle permettant d’implementer GVA dans Duniter, tout en développant Cesium2.

Si c’est pas possible, peut-on se planifier un créneau de travail commun en 2020 ? Césium est né en 2016, un refonte en 2020 me paraît bien :slight_smile:

Merci a toi !

Bonjour,
pour info avec @jsprenger on commence à implémenter le schéma du module GVA de Dunitrust.
Dunitrust ne possède pas encore de module mempool et la librairie que l’on utilise ne gère pas encore les subscriptions. On va donc dans un premier se limiter aux query des données inscrites en blockchain.

5 Likes

Salut @ji_emme !
Ce qui serait chouette, c’est que je puisse faire interagir Cesium2 au fur et à mesure, sur un noeud ayant un début d’API GVA.
Cela permettrait de faire du pseudo-Scrumb, en restant focaliser sur les besoins réels et prioritaires des logiciels clients.
C’est aussi un moyen de rester motivé, car quand vous publier une nouvelle fonction, plusieurs personnes peuvent tester et juger des perf, du bon fonctionnement, etc.

Bref, est-ce que cela vous semble jouable d’avoir un cycle de développement interactif la dessus ?

2 Likes

Oui, c’est déjà le cas pour Dunitrust, je présente ça vendredi :slight_smile:

Alors niveau perf on commence par une implémentation naïve donc pas optimisé, j’ai déjà plein d’idées d’optimisations mais que je mettrais en place dans un second temps.

De mon point de vue oui :smiley:, reste a voir la dispo de @ji_emme et @jsprenger la dessus mais il ne sont pas seuls, je les accompagnent :blush:

:+1: :+1: Je suis carrément motivé pour des cycle de développement interactif!
Les avantages que ça apportes sont en effet très nombreux.

2 Likes

Pour moi ça me va bien aussi. Itératif et interactif ça évitera de développer un peu à l’aveugle vis à vis des besoins des logiciels client.

2 Likes

Ah bon ? J’imagines que tu as du modifié Cs2 pour que ca marche, non ?

Je répondais à ça, je disais juste qu’il y a un début d’api gva, bien sur que je n’ai pas touché a Cs2 :sweat_smile: