Je ne sais pas du tout où en est le développement de GVA.
Je me dis juste qu’utiliser https://hasura.io pourrait peut-être accélérer la mise en place d’une API graphQL.
Hasura construit directement une api graphQL sur une base de données postgresQL (et bientôt mySQL) et gère les subscriptions. Ça éviterait de construire toute l’api à base de typeDefs et resolvers…
Je ne sais pas s’il est possible de convertir la bdd sqlite de duniter avec pgloader…
J’utilise Hasura depuis 2 ans et c’est vraiment un pur bonheur ; puissant, rapide et léger.
C’est juste une idée !
Ajouter une base de données SQL lourde risque de rendre Duniter plus difficile à maintenir et installer.
On est plutôt partis sur une db rust légère.
Hasura reste à comparer avec Apollo qui semble équivalent…
Mais tout cela reste du nodeJS.
L’ oxydation de Duniter est vraiment un plus en terme de performance/consommation, et donc le module GVA sera sûrement en Rust… Voir avec @elois.
1 Like
Si j’ai tout bien suivi, Duniter n’utilise plus que LevelDB actuellement, et plus du tout SQLite. (ça nous a d’ailleurs bien embêtés pour développer des clients : LevelDB ne pouvant être ouvert en lecture par un seul thread, il fallait arrêter Duniter pour lire les index)
Intégrer une db légère (sled aux dernières nouvelles) plutôt qu’utiliser une usine à gaz externe et polyvalente permet de rendre le tout plus portable.
1 Like
En effet j’ai déjà prévu de baser GVA sur sled, j’ai déjà la couche de souscription et tout ce qui va bien.
Ce qui bloque ce n’est pas la DB, ce qui bloque c’est la création des traitements métier d’indexation de bloc qui vont remplir la base dédiée à GVA.
Non ça c’est rien ce n’est même pas 1% du boulot.
Ce que tu proposes @ManUtopiK ne ferait que rallonger fortement le développement de GVA tout en rendant Duniter plus lourd et moins portable et en compliquant sa stack, j’espère que tu comprend bien que ce n’est pas envisageable 
2 Likes
À propos de sled, puisqu’il n’est pas lisible par plusieurs processus, est-ce que GVA permettra de lire les données avec au moins les mêmes performances que directement LevelDB ? C’est pour les programmes qui piochent les données directement dans la bdd…
Ok, merci pour vos réponses.
Oui, j’ose pas imaginer pas le boulot qu’il y a derrière tout le reste !!!
En effet, ça compliquerait la stack. Je me disais que ça pouvait peut-être simplifier l’API. Mais oui, il y a aussi toute la logique métier à créer et Hasura ne simplifie les choses que si les requêtes sont simples…
Hasura est écrit en Haskell. Ça évite justement d’avoir un serveur Apollo qui construit les requêtes postgres…
Je dirai même meilleures puisque sled est plus rapide en lecture que leveldb, et la couche GVA sera en full async rust donc quasiment transparente en termes de délai d’accès supplémentaire, vous ne sentirez même pas de différence.
Ce qui est une mauvaise pratique car ça vous rend dépendant du schéma interne de la DB, dont seul Duniter devrait dépendre. Je suis ok pour maintenir une API selon les besoins de ceux qui se basent dessus, c’est fait pour ça une API, par contre il est hors de question de maintenir une certaine structure de DB pour des programmes extérieurs à Duniter.
3 Likes