ĞDev indexer

[HugoTrentesaux]

Et maintenant, grâce à @ManUtopiK qui a publié le code de https://git.duniter.org/manutopik/duniter-indexer (j’ai complété la doc d’installation), nous avons un endpoint GraphQL public https://duniter-indexer.coinduf.eu/v1/graphql que vous pouvez tester dans une interface graphql comme https://graphiql-online.com/graphiql en attendant la prochaine release de Ǧecko qui l’utilise déjà !

(laissez un peu de temps à l’indexeur de finir de rattraper mon nœud rpc lui-même en train de rattraper le reste de la blockchain)

[elois]

Félicitations @ManUtopiK

Bon j’avais déjà vu les avancées en coulisse et est passé du temps à t’aider à bien concevoir tout ça aux RML et après, mais tu as été très rapide pour maturer le projet

J’ai juste 2 petites remarques sur les dernières avancées :

• Le numéro de bloc, nommé aussi hauteur de bloc, devrait être nommé number ou height, le terme actuel (index) ne conviens pas.
• Les identités du genesis sont indiquées comme créées au bloc #1, alors qu’elles sont créées au bloc #0

[elois]

@ManUtopiK ce serait bien de fournir une image docker pour l’indexer, ainsi je pourrais l’ajouter au compose de mon nœud d’archive pour héberger une instance

EDIT: Aussi on ne devrait pas avoir besoin d’installer hasura cli pour initiatiser la DB, on doit pouvoir faire ça uniquement via une config dans le compose sur un ou plusieurs micro-services, il faut donc que l’un des micro-service s’occupe d’initialiser les metadata et de run les migrations. Je vois dans la doc d’hasura que c’est possible: Auto-apply migrations/metadata when the server starts (config v2) | Hasura GraphQL Docs (lien v3).

[ManUtopiK]

Ok, je met docker dans ma todo list.
Je ne savais pas qu’on pouvais appliquer les migrations et metadata au démarage.
Le lien pour la config v3 : Auto-apply migrations/metadata when the server starts | Hasura GraphQL Docs
Je vais intégrer ça…

[elois]

@ManUtopiK

Ok, je met docker dans ma todo list.

@ManUtopiK je te recommande de builder et publier l’image docker directement depuis la CI, tu as plein d’exemples dans les dépôts du groupe docker: docker · GitLab

Si tu as besoin d’aide je peux t’aider en visio, je pense que ça vaut le coup que tu apprennes à le faire, c’est des compétences qui te seront utiles

@ManUtopiK

Je ne savais pas qu’on pouvais appliquer les migrations et metadata au démarage.

C’est l’inverse qui aurait été étonnant, je suis parti du principe que c’était forcément possible, car c’est nécessaire pour pouvoir déployer en prod avec docker, à partir de là j’ai juste cherché dans leur doc et j’ai trouvé en 5 min

Mais ça me semble souhaitable que pour la prod, le mieux c’est que tu es 2 docker-compose, un pour le dev et un pour la prod, car les besoins ne sont pas les mêmes

[cgeek]

@elois

je te recommande de builder et publier l’image docker directement depuis la CI, tu as plein d’exemples dans les dépôts du groupe docker: docker · GitLab

Tiens justement, où peut-on trouver le job qui build l’image duniter/duniter-v2s ?

[HugoTrentesaux]

@cgeek

Tiens justement, où peut-on trouver le job qui build l’image duniter/duniter-v2s ?

bah ici, non ? https://git.duniter.org/nodes/rust/duniter-v2s/-/jobs

[cgeek]

Ah bah oui, j’ai bêtement suivi le lien qui parlait du groupe docker contenant les projets d’exemple. Mais en effet, merci.

[elois]

@cgeek c’est le job deploy_docker_release_tag tout à la fin du fichier .gitlab-ci.yml:

.gitlab-ci.yml · master · nodes / rust / Duniter v2S · GitLab

Mais la CI de duniter-v2s n’est pas un bon exemple pour débuter, car elle est complexe, j’utilise un « template de job » car je build plusieurs types d’images selon les conditions, et en plus je récupère le binaire buildé dans un autre job, afin de ne compiler qu’une fois.

Pour débuter il vaut mieux s’inspirer d’une CI plus simple, comme celle-ci par exemple: .gitlab-ci.yml · master · docker / dunitrust / dunitrust-rs-ci · GitLab

[cgeek]

@ManUtopiK

Je vais intégrer ça…

Si tu veux je viens de te faire une MR.

[ManUtopiK]

Génial ! Merci

[ManUtopiK]

Bon, avec tout ça, j’ai pris du retard sur mon taf, puis la fin d’année scolaire tout le monde s’excite…
Je vais pas trop pouvoir me mettre dessus cette semaine.

Du coup j’ai créé des tickets, si ça vous avez envie de contribuer !

Issues · Emmanuel Salomon / duniter-indexer · GitLab

@elois Il y a pas le feu, mais si tu peux jetter un oeil sur pourquoi la subscription au storage ne retourne rien ? Est-ce que c’est bien le bon ?

[elois]

@ManUtopiK

Bon, avec tout ça, j’ai pris du retard sur mon taf,

Oui moi c’est pareil haha, je vais être obligé de lever un peu le pied

@ManUtopiK

Du coup j’ai créé des tickets, si ça vous avez envie de contribuer !

Est-ce quelqu’un peut ajouter la dockerisation ? peut-être @Pini ?

@ManUtopiK

@elois Il y a pas le feu, mais si tu peux jetter un oeil sur pourquoi la subscription au storage ne retourne rien ? Est-ce que c’est bien le bon ?

C’est juste ton préfix qui n’est pas bon, je t’ai répondu dans l’issue dédiée

[cgeek]

J’ai tenté de faire un build Prod, mais j’ai rencontré l’erreur pnpm start: ERR_REQUIRE_ESM. Aurais-tu une piste ?

[ManUtopiK]

Oui. Je suis parti avec mon boilerplate fastify-vite qui utilse vite-plugin-node qui est bien pratique quand on fait du front, mais pas trop pour cet indexer en fait.
Et mon plugin fastify-hasura marche pas avec vite parce qu’il est fait en type module (import … from …) ou peut-être que c’est juste qu’il a type:module dans le package.json.

Bref, pas eu le temps de corriger tout ça…
Soit je vire vite, mais c’est dommage car on perd vitest qui est excellent. Soit je met à jour mon plugin fastify-hasura…
J’aurais plus de temps la semaine prochaine pour ça.

[Pini]

@elois

Est-ce quelqu’un peut ajouter la dockerisation ? peut-être @Pini ?

J’ai pris quelques jours de vacance. Je jetterai un oeil.

[cgeek]

J’ai déjà regardé, mais pas encore publié. En fait comme indiqué ci-dessus je bloque sur le build « prod » avec l’erreur ERR_REQUIRE_ESM, qui nécessite une expertise un peu trop coûteuse pour moi, @ManUtopiK sera plus efficace.

[kimamila]

Salut à tous !

De mon côté j’avance aussi, avec un indexeur ES sur la GDev, qui me permettra de maintenir les services Cesium+ et Gchange (suivi des TX pour les financements participatifs).
Il a une lib PolkaJ qui permet d’accéder à l’API RPC, en Java, et qui me va très bien (pour le moment).
Il sera ensuite facile de mettre en place une API GraphQL au dessus du cluster ES, pour servir les logiciels clients (wallets).

J’utilise PostgreSQL au boulot, en prod, et je peux assurer que les perfs n’ont rien à voir. Et puis je voudrais faire en sorte que l’existant continuer de fonctionner.
Après si on peut harmoniser les API GraphQL qui en sorte, c’est mieux. Mais de toute manière je n’en suis pas encore rendu là.

a+