Merci pour ce checkpoint.
J’ai fait les changements sur Ğcli quand j’étais chez toi mais j’ai oublié de les pousser, je fais ça.
Mais c’est un wip, car il reste un “bug” (enfin c’est une feature) que tu n’a pas mentionné et que j’étais en train de traiter avec un autre jolie wip côté indexer sur la branche convert-hash-bytes-to-hexa: wip (50c8b561) · Commits · nodes / duniter-squid · GitLab
Le format des hash en DB sont des bytes, et sont donc affiché avec \\ au lieu de 0x via l’API graphql hasura.
Plutôt que de parser ça comme un mal propre côté gcli j’ai voulu traiter le problème à la racine, côté indexer.
Ca fonctionne mais le soucis c’est que ça m’oblige à créer un computed field qui convertie au bon format, et donc un nouveau champ graphql style hashHexa. Des plus ça demande à traiter ça pour chaque hash, je n’ai pas encore trouvé de solution générique.
Les enums sont également en wip sur une branche, plus compliqué que prévus …
Lors de tests rapides, on constate qu’en terme de latence, le moteur graphql de squid et celui de Hasura sont dans le même ordre de grandeur, mais avec une légère réactivité supplémentaire relevé avec le moteur de squid.
Je vais finir de traiter ces derniers points, mais je dois avouer que l’intégration de Hasura a été bien moins straightforward qu’annoncé. C’est dû au fait que le schéma de base de donnée n’est pas aussi expressif que ce que je pensais. Certaines informations ne sont présente que dans le schema.graphql, et malgré le parseur typeORM de squid, cela a nécessité la génération de certaines migration SQL squid custom.
Je vais finir par arriver au bout de cette intégration Hasura, et ça me semble proprement intégré et facile à maintenir et faire évolué vue que j’ai automatisé pas mal de choses, mais plus j’avance, plus je me demande si le jeu en vaut la chandelle.
Une fois terminé je reprendrais un tableau comparatif plus complet pour comparer les deux solutions.