Superbe ! C’est hyper clair
Je me pose une autre question : comment traiter le cas des recherches d’identités avec GraphQL ? (Recherche en piscine, hors-piscine, etc)
Superbe ! C’est hyper clair
Je me pose une autre question : comment traiter le cas des recherches d’identités avec GraphQL ? (Recherche en piscine, hors-piscine, etc)
Super ! Quand ta RFC sera assez avancée tu pourras créer une Merge Request avec la mention “WIP:” pour que l’on puisse commenter facilement ton document.
En adaptant la proposition de Inso en GraphQL, pleins de questions/solutions me chauffent le cerveau et je vais vous exposer ici ma vision d’une API client.
La Blockchain stocke des Documents.
Cette suite de documents créent des événements qui sont en fait des changement d’Etats.
Certains états sont déjà calculés et stockés dans la Blockchain (comme la Masse Monétaire dans un bloc avec DU).
Certains Etats sont déjà calculés et stockés dans la Base de données (comme le solde des portefeuilles : Balance).
Certains Etats ne sont pas calculés et doivent l’être par le client à l’aide de l’Historique des Documents.
Pour concevoir l’API, ils faut bien distinguer les TYPES de données dont le client a besoin.
Ce sont surtout des Etats.
Donc la priorité est de lister les différents Etats des données.
Si des Etats manquent dans la base de données de Duniter, le module Duniter de l’API peut s’occuper de les calculer dans une table dédiée de la Base de Données.
Le but est que le client ne doivent jamais recalculer lui même un Etat via l’historique des Documents.
La Piscine reçoit aussi des documents, et peut donc générer des Etats, mais souvent incomplets ou en attente et différents selon les noeuds. Pour moi les informations de la piscine sont à gérer à part. Avec des requêtes spécifiques.
Viendront ensuite les Listes de données (recherches, etc).
Dans le document RFC, pour commencer, je vais lister les Etats nécessaires au clients.
Il y aura des Etats dédiés à l’affichage dans le client et non stockés dans Duniter, ne correspondant à aucun Document connu. On verra après comment les calculer côté serveur.
Tout à fait d’accord. C’est un peu ce que je décrivais dans mon post original, d’après moi il doit y avoir 2 BDD :
Pour la seconde BDD, je vois plutôt un seul Etat par données à l’instant t, donc peu d’historiques, sauf si ceux de la BDD de flux sont trop long à extraire… Pour moi l’archive c’est déjà la Blockchain.
Justement, extraire ce flux de la BDD “flux” peut être long (c’est pour ça que plein de choses ont été retirées de BMA et que Sakia le fait maintenant manuellement… et que c’est super long) car il faut reparcourir toute la chaine à chaque requête :
J’ai terminée la base de départ de la RFC, vous pouvez commentez l’améliorer, la modifier, etc.
J’ai ajouté un chapitre sur la seconde Base de données qui pour moi doit être en json (NoSQL).
Sqlite permet de faire cela, comme PostgreSQL. On a un mini ElasticSearch à disposition dans un fichier Sqlite !
Je remets le lien, de plus il a changé :
Pour le nom, j’hésite entre GVA (GraphQL Verification API) et GMA (GraphQL Merkle API)…
Perso, j’avais déjà adopté GVA, et puis c’est mieux de faire rupture avec l’ancienne BMA, et je trouve que GMA c’est trop proche, certains vons croire que c’est la même chose, GVA fait rupture, on comprend clairement que c’est qqch de nouveau
Si je vous dit que par consonnance j’entends GPA, c’est gênant ?
haha non ça fait progressiste
ben je comprends rien au sens du progrès, alors… ceux qui n’ont pas connu leur vrai mère comprendront…
Pour info, il y a un application exemple GraphQL + sqlite : https://github.com/mrblueblue/graphql-express-sqlite
J’ai testé et ca fonctionne plutot bien. Par contre il va falloir spécifier tous les types retourner, par chaque requete…
A propos de la nouvelle API, y a t-il un moyen de savoir quand un nœud est offline?
Oui je prévois un système de gestion avancés des status de chaque nœuds dans ws2p v2 ou 3, et dans l’idéal il faudra que la nouvelle api client relaye ces infos aux clients qui le souhaitent, mais cette nouvelle api client en est encore aux spec, et surtout je ne sais toujours pas qui va la coder, je pourrais aider pour l’interface avec ws2p mais je ne projette pas de dev cette nouvelle api client, j’ai déjà beaucoup trop d’engagements de dev compte tenu du temps dont je dispose !
Donc la vrai question est là, qui vas dev GVA ?
Pour info les spec se discutent ici : WIP: RFC 3 : GraphQL API for Duniter Client (!3) · Merge requests · nodes / common / doc · GitLab
Un article très intéressant sur les différences entre une approche REST et GraphQL pour une API :
Pourrait on en parler au RML11 ?
Je pourrais vous faire un démo d’un projet sur lequel je travaille : application web avec des technos proche de celles de Cesium, mais en versions plus récentes (Ionic 4 + Angular JS 5), et avec du GraphQL (API JS cliente Apollo)
Oui ça serait bien qu’on se fasse une séance de discussion là dessus. Quitte à faire ça en parallèle d’un autre atelier technique.
Je vais en toucher mot vendredi matin car je ne vais pas recoder BMA dans duniter-rs et il me faudra bien une api client, donc je compte bien qu’on implémente directement une api GraphQL basée sur la RFC en cours de proposition, d’autant qu’il y a une crate rust mature pour GraphQL
Par contre j’ai tellement d’autres priorités d’abord que je ne commencerai pas avant 2019, après si d’autres contributeurs me rejoignent ça pourra aller plus vite
J’avais dû rater cet article. J’ai du être inspiré par un trou noir.
C’est super les réflexions que vous avez faites !
Ça a donné quoi les discussions à la RML11 ?