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
@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 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
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 c’est le job deploy_docker_release_tag tout à la fin du fichier .gitlab-ci.yml:
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.
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 !
@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 ?
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.
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.
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à.
@poka voudrais-tu bien tester de brancher Gecko dessus ? Il me semble que tu peux le faire.
Tu devrais avoir des données plus à jour car l’indexeur était buggué et ne réalisait qu’une indexation initiale et n’indexait pas les blocs suivants, or j’ai corrigé ce point sur mon noeud.
