Développeur Java avec envie de contribuer à ce beau projet

Bonjour à tous,

J’ai découvert récemment la Ğ1 et j’ai envie de commencer à mettre les mains dans le cambouis pour apporter ma pierre à l’édifice.

Pour ma part, je suis développeur Java. J’ai vu que le projet Cesium + Pod était en développer en Java et pourrait être un bon début pour commencer à contribuer à tout ça.

Si besoin, étant formateur Git dans le cadre de mon emploi, je peux aussi aider sur de l’accompagnement si besoin (configuration, déblocage lors de mauvaises manipulation ou autre).

Pour cela, je veux bien un accès sur le gitlab afin de commencer à y faire mes premières MRs.

Vous pouvez me contacter en MP si besoin :wink:

Au plaisir d’échanger avec vous,
Benoît.

9 « J'aime »

Compte créé sur notre GitLab. Je te laisse faire le nécessaire (changement de mot de passe) pour rentre le compte actif.

Bienvenue et bonnes contributions !

2 « J'aime »

Super, Merci pour la réactivité :wink:

Bienvenue à toi !

Pour info le Pod Césium+ est écrit en Java oui, mais sur une veille version de ElasticSearch.

Pour la suite, il faudrait savoir si on peut toujours utiliser ES après migration de Duniter sur Substrate. Je ne maîtrise pas cette partie…
Si oui, et si utiliser ES est toujours utile, alors je comptais plutôt réécrire le Pod en Spring-Boot, avec ES derrière mais sans plugin ES : la logique métier serait donc uniquement dans le code du Pod, et le cluster ES pourrait être agnostique fonctionnellement. Ça me semblerait plus pérenne.

Je penses avoir besoin de migrer le Pod, aussi car je m’en sert pour changer (même code pour la gestion des profils, messages privés, suivi des blocs, suivi des peers, et gestion des notifications d’événements).
Mais ça sera quand même un gros boulot…

L’autre chantier est la réécriture de Césium, en Angular 12 / Ionic 5 qui s’interface avec les noeud Duniter 2S (Substrate).

1 « J'aime »

De quelles informations à tu besoin pour pouvoir répondre à cette question ? :slight_smile:

Cool, pouvoir mettre à jour ES sans trop de contrainte est toujours une bonne chose.

Je ne connais pas encore bien l’infrastructure du projet ni celle de Duniter mais il me semble que l’utilisation du pod par Duniter ne tient pas compte de ce que nous utilisons. Du coup, je ne vois pas ce qui pourrait restreindre l’utilisation d’ES avec Subtrate. Si j’ai bien compris, on fournit une API qu’ @elois peut appeler directement.

Dites-moi si je me trompe mais il me semble pas que nous ayons ce genre de contrainte.

Sinon, pour la version actuelle du Pod, j’ai regardé un peu les issues remontées. Elles sont toujours d’actualité @kimamila ?

Merci à tous pour l’accueil :wink:

Duniter n’utilise pas les Cesium+ pod, c’est l’inverse. Je n’ai jamais utilisé l’API des Cesiom+pod, et je n’ai pas prévu de le faire un jour.

Les cesium+ pod ne sont pas nécessaires au fonctionnement de la blockchain, ils servent à deux choses:

  1. Fournir une meilleure API aux clients pour accéder à l’historique des données en blockchain.
  2. Stocker des données utilisateur qui ne sont pas stockées en blockchain.

Pour le point 1. je pense qu’une solution comme Hydra peut entièrement gérer ça.

Ha mon humble avis, les Cesium+ pod ne resterait pertinent que pour le point 2.

1 « J'aime »

Oui, c’est ce que je comprends.

Du coup, @kimamila , sur quel point t’interroge-tu concernant ES vis à vis de Duniter ?

Ce qui m’interroge, c’est comment détecter des évènements issus de la blockchain, par exemple les TX, les certifications, etc pour en générer des notifications (=document json) stocké dans ES.

Dans les noeuds actuels, il est possible :

  • de demander une plage de blocks (qui sont retourner en json) : utile pour la première synchronisation des Pod Césium+
  • de s’abonner aux nouveaux blocks, via une websocket. C’est ce que j’utilise pour la détection des forks et la création régulière, au fil de l’eau, des notifications d’événements.

Je ne sais pas s’il possible d’accéder simplement a cela. De ce que je comprends il faudra passer par Hydra (graphql over postgresql) mais il reste à faire une PoC sur ce sujet.

Ça t’intéresse @CaTasTrOOf ?

C’est un peu poussé pour moi pour l’instant, je vais déjà commencer par me familiariser avec le fonctionnement actuel pour, ensuite, envisager de faire ce genre de PoC.

J’ai besoin de comprendre un peu tout le fonctionnement global encore. Mais pourquoi pas plus tard, je ne sais même pas la quantité de travail que cela représente :smiley:

Je pense qu’il serait plus pertinent que les pod Cesium+ ne synchronisent plus la blockchain, j’explique plus bas pourquoi, mais si vous tenez absolument à le faire, il y a 3 possibilités:

  1. Passer par l’api libp2p, c’est celle qui est utilisée par les nœuds substrate pour se synchroniser entre eux: très difficile et je ne peux pas vous aider là-dessus.
  2. Passer par un indexeur tier comme Hydra.
  3. Requêter les blocs un par un via l’API RPC, c’est ce que fait Hydra lors de la sync initiale, c’est long mais comme Hydra ne récupère que les blocs finalisés ont à la garantie de ne le faire qu’une fois, sauf corruption irréversible de la DB postgres (ce qui est extrêmement improbable) ou perte de données de la part du gérant du nœud Hydra, il suffit alors de sync à partir de la dernière backup, donc en tous les cas pas besoin de resync toute la blockchain.

À noter que par défaut un nœud substrate ne conserve que les 256 derniers blocs, il faut donc de toute façon connaître des nœuds d’archive sur lesquels se baser.

L’API RPC propose plusieurs souscriptions intéressantes pour ça, mais pour des raisons de performance tu ne peux souscrire qu’aux headers des blocs, à toi ensuite de requeter le bloc complet s’il t’intéresse. Tu peux souscrire aux headers via 3 méthodes différentes:

  • chain_allHead: Te donne les headers de tout les blocs reçus par le nœud (fork inclus)
  • chain_newHead: Te donne uniquement les headers correspondant aux blocs sur la best chain, c’est à dire la branche considérée comme la bonne par le nœud.
  • chain_finalizedHead: Te donne uniquement des headers des blocs finalisés, c’est la souscription utilisée par les indexeurs hydra, ils n’indexent que les blocs finalisés pour ne pas avoir à gérer les forks.

Concernant les notifications d’évènement, sache tout d’abord que tu peux t’abonner aux évènements générés par un extrinsic que tu envoies, pour cela il faut envoyer l’extrinsic en websocket via la méthode RPC author_submitAndWatchExtrinsic.

Tu seras alors notifié dès que l’extrinsic sera en blockchain, avec la liste des évènements substrate qui auront été générés par l’exécution de l’extrinsic. Si tu continues d’écouter la souscription, tu recevras une nouvelle notification lorsque le bloc contenant l’extrinsic sera finalisé (entre 30 secondes et 1 min quand le réseau se porte bien).

En termes d’UX ça te permet de soumettre 2 niveaux de notifications à l’utilisateur après chaque action (=extrinsic) soumise à la blockchain. Tu peux l’associer à une icône de check à 2 états, par exemple comme fait signal pour différencier le fait qu’un message a été reçu eté qu’il a été lu

Et concernant les autres types de notification, ça on peut ajouter ce qu’il faut à l’API RPC, il nous faut juste définir la liste des évènements auquel on doit pouvoir souscrire.

Concernant tout ce qui est notifications, Hydra n’est pas fait pour, comptez plutôt sur l’API RPC pour ça.

En revanche, concernant l’indexation des données de la blockchain il me semble plus pertinent de vous baser exclusivement sur Hydra, car on peut y customiser entièrement ce qu’on veut stocker et sous quel format via du code typescript.

Ce qu’il faut comprendre, c’est que Hydra est conçu en 2 couches distinctes, avec chacune leur API GraphQL (oui il y a 2 api graphql): l’indexer et le processor.

L’indexer indexe de façon brute toutes les données de la blockchain dans un format générique commun à toute blockchain substrate, il a sa propre base de donnée (postgresQL) et expose une API GraphQL pour y accéder.

Le processor nécessite qu’on lui fournisse des « routines » typescript, il va consommer l’API graphQL de l’indexer et injecter les données dans les routines typescript, qui vont permettre de traiter les données comme on le veut, puis de les stocker dans une 2ème DB postgesQL séparée.

À mon humble avis, les pod Cesium+ ne reste pertinent que pour un seul et unique besoin: stocker les données des utilisateurs qui ne sont pas en blockchain (profils utilisateurs, messages privées, etc).

Pourtant on peut créer des events handlers avec hydra ? L’idéal pour créer des notifications non ? Si le handler peut appeler une api ou mettre en queue tasks alors on peut gérer des notifications.

Hydra est en postgresql, je ne vois pas l’intérêt de venir mettre de l’elasticsearch en plus…
Aussi, je ne suis pas fan de ses gros machins qui font tout. Ce serait plus intéressant d’avoir une architecture micro-services avec Hydra (ou une app lié à Hydra) qui dispatch sur des services qui ne font qu’une chose.

Et franchement, des outils comme Hasura, Supabase, Postgraphile, Wundergraph… serait carrément mieux adapté pour ça (merge graphql schema, trigger api on insert/update/delete postgresql events on a datatable, cron/schedule…)

Un autre framework qu’Angular est-il envisagé ?
Il faudrait d’abord une lib agnostique en js. (polkadot ?)

1 « J'aime »

@elois Il y a déjà un repo substrate/Hasura GitHub - playzero/substrate-graph: a compact graph indexer stack for parity substrate, polkadot, kusama
Mais il n’a pas l’air d’être très mis à jour. Tu en sais plus ?

Et si je veux monter une instance Hydra, est-ce que je dois avoir un nœud Duniter 2S ?

J’aurais du précisé « notifications instantanées », l’inconvénient d’Hydra c’est que les données les plus récentes qu’il fournit ont déjà plusieurs minutes de retard (dans le meilleur des cas), car il n’indexe que les données finalisées, et il faut rajouter le temps de passage dans toutes les couches d’indexation.

L’api RPC peut fournir des notifications instantanées, dès que la donnée vient d’arriver on chain, puis une 2ème notif dès que la donnée est finalisée.

Après tout dépend des besoins, dans les cas ou plusieurs minutes de latences ne sont pas gênantes, alors utiliser Hydra pour les notif conviendra :slight_smile:

Malheuresement non :confused:

Pour le moment oui, le plus simple est d’utiliser l’image docker que je fournis, voir ici: Tester duniter-v2s avec l'image docker de test (debug-sha-********)

Ce serait génial si tu pouvais tester Hydra avec Duniter-v2s, si tu as besoin d’aide on peut se faire une visio ou discuter en MP :smiley:

2 « J'aime »

Je suis du même avis que @ManUtopiK et Elois, il serait plus avantageux d’utiliser des projets robustes développés par d’autres que nous et déjà dédiés à Substrate comme Hydra pour les données blockchain.

Pour les données utilisateurs supplémentaires, j’irai même d’abord regarder dans Hydra si cela est possible d’ajouter ses propres données attachées à des données blockchains.

Et si cela n’est pas possible, je partirai sur une techno analogue pour profiter de la database PostgreSQL (que je connais bien en plus et sur laquelle je peux aider) et de ses données blockchain et ainsi réduire le nombre de dépendances à installer et de techno à maîtriser. Et accessoirement, il n’y a pas de problème de licence avec PostgreSQL contrairement à ES.

Un nœud complet pour les clients de Duniterv2s ce serait donc (@elois corrige moi si besoin) :

  • Subtstrate (en mode archive ?) - compilé du Rust ?
  • Le « client » substrate duniterv2s - compilé du Rust - Api RPC
  • L’indexer avec index personnalisés - Hydra - nodejs/PostgreSQL 12 - API GraphQL
  • DONNEES UTILISATEURS : Hydra? Hasura ? - language X/PostgreSQL 12 - API GraphQL

Les dépendances sont nodejs et PostgreSQL à priori.

Oui, sauf que les 2 premières lignes sont confondues en un seul et même binaire.
On peut faire un docker compose dans lequel le nœud duniter+v2s n’est qu’un micro-service parmi d’autres, Hydra étant lui-même découpé en plusieurs micro-services.

1 « J'aime »