Subsquid (ancienne Hydra): indexer de blockchain substrate exposant des API GraphQL

elois · 29 January 2022 21:08

Squid remplace Hydra qui n’est plus maintenu.

J’ai réussi à faire fonctionner l’indexer de Squid avec Duniter-v2s en m’inspirant des dockers compose qu’ils donnent dans ce dépôt : GitHub - subsquid/squid-archive-setup: Squid Archive setups for various chains

J’ai commité dans le dépôt de Duniter-v2s un docker compose qui permet lancer un nœud duniter-v2s avec un indexer Squid fonctionnel :

L’API GraphQL de l’indexer est alors accessible à l’adresse localhost:4010/console.

C’est une API brute , commune à toute blockchain substrate, et difficile à utiliser.

L’étape suivante est de générer des définitions typescript: https://docs.subsquid.io/recipes/generate-typescript-definitions
Puis définir les schémas GraphQL métier que l’on veut: Define a Squid Schema - subsquid
Puis mettre tout ça dans un nouveau dépot git basé sur ce template: GitHub - subsquid/squid-template: Squid project template
Enfin créer une (ou plusieurs) image·s dockers de ce processor pour que ceux qui souhaitent fournir l’API métier puisse intégrer ce qu’il faut à leur docker compose.

@ManUtopiK, @kimamila et @1000i100 j’aimerais bien que vous puissiez travailler là-dessus, tout autre développeur typescript est bienvenue

Je peux vous aider pour le setup et fournir les explications nécessaires, on peut se faire des visio pour ça, tant que c’est le week-end ça me va

elois · 29 January 2022 23:00

Je viens de bidouiller avec le template de Squid, j’ai réussi à faire fonctionner leur processor de base qui indexe l’historique des soldes, mais il ne se base que sur l’event “Balances.transfer”, donc ça ne capte pas les DU.

J’ai rajouté la gestion de l’event “Balances.Deposit” (event lié à la création du DU, et ça maaaaarche !!!
J’ai l’historique complet et correct du solde de chaque compte

J’ai créé un nouveau dépôt avec mon fork du Squid template, je savais pas trop où le mettre alors le l’ai placé dans tools, hésitez pas à me suggérer un emplacement plus pertinent

Il n’y a plus grand-chose à modifier pour fournir directement l’historique des transactions et des créations de DU, j’aimerais bien que des dev Js/Ts prennent la suite

@ManUtopiK on se fait une visio ?

1000i100 · 30 January 2022 10:30

Par rapport à faire un proxy BMA vers Gecko, ça te semble jouable et pertinent de faire un indexer squid qui requête BMA histoire que coté client/wallet, ceux qui migrent sur graphql basé sur squid puisse le faire sous peu en sachant que BMA allimente ça et qu’il n’y ait qu’à débrancher BMA et rebrancher substrate pour que le proxy face son office sans besoin de changement coté client/wallet ?

Question subsidiaire :
tu avais listé un certain nombre de critères pour te baser sur un framework et substrate cochait toutes les cases (maintenu par pas mal de monde, utilisé largement, depuis un certain temps…).
Le fait que Hydra ne soit plus maintenu et que tu bascules sur squid qui m’a l’air très jeune m’interroge et m’inquiète : ne risque-t-on pas de se retrouver avec la charge d’un existant que l’on maitrise mal et qui serait abandonné par sa communauté d’origine en quelques mois ou au plus d’ici 1 an ou 2 ?

ManUtopiK · 30 January 2022 11:18

Carrément partant pour t’aider sur cette partie-là ! Et oui, ce serait bien de se faire une visio

elois · 30 January 2022 14:19

Non squid est conçue pour indexer une blockchain substrate, on ne peut pas indexer autre chose avec.

J’ai rencontré l’un des dev de subsquid dans le cadre de mon boulot, ils ont récupéré les droits sur Hydra, et fournissent des services d’indexation pour beaucoup de grosses crypto, dont Moonbeam pour pou qui je travaille, et Polkadot/Kusama bien sur. Tous les projets qui se basaient sur Hydra se base sur Squid maintenant, c’est les mêmes technos et le même principe, c’est juste un changement de nom.
Il faut également savoir que Squid est en partie financé par la web3 fondation qui finance Substrate, ils ont beaucoup de fond et tout va bien pour eux.

1000i100 · 30 January 2022 15:26

ça répond pour l’avenir de subsquid. En revanche, ça me semble étrange qu’il soit aussi inconcevable de nourrir l’indexer de subsquid avec autre chose que du substrate… Ou alors ça m’inquiète un peu quand à l’architecture de subsquid.

Pourquoi ne pourrais-je pas, via l’indexeur ou en me brancheant à un autre niveau, allimenter la bdd d’une instance subsquid à partir de données BMA histoire qu’en aval le requetage puisse se faire à l’identique ?

elois · 30 January 2022 15:38

Je pense que tu peux, subsquid est conçu en micro-services, tu peux recoder entièrement a ta sauce le micro-service processor qui s’occupe de remplir la bdd PostgresQL, et réutiliser tel quel le micro service qui expose l’API GraphQL donnant accès à la DB PostgresQL.

Mais le schema de la DB va dépendre de ce qu’on veut exposer, et le temps qu’on définisse ça avce les dev des wallet…

Le mieux ce’st qu’on se programme une visio dédiée à ce sujet juste toi, moi et @ManUtopiK s’il est dispo car je sais qu’il connaît bien ure partie des technos utilisées par subsquid (apollo).

1000i100 · 30 January 2022 16:18

@elois @ManUtopiK Dimanche 6/02 à 18h ?

elois · 30 January 2022 16:24

ok pour moi

ManUtopiK · 30 January 2022 17:25

La semaine prochaine, je ne peux vraiment rien faire. Je serais bcp en déplacement et pas bcp sur l’ordi…
Il faudrait que je teste tout ça voir dans quelle mesure je peux m’impliquer avec mes connaissances.
Je suis dispo toute la semaine d’après quand vous voulez. Ça peu être Dimanche 13/02 à 18h. Ou avant, je m’adapte…

1000i100 · 30 January 2022 17:30

Si j’ai bien suivi, @elois préfère réserver les visios aux WE.
En WE, je peux le 6/02 à partir de 18h, le 12 et 13 (à partir de 14h), et le 20.
Je me demande s’il ne serait pas pertinent d’inclure @poka aussi.

elois · 30 January 2022 20:36

Va pour une visio spéciale subsquid le Dimanche 13 février à 18h !

On peut inviter en 1ère partie les dev des wallet, qui seront donc potentiels utilisateurs de cette API, cc @kimamila @poka @vit et @Moul

Mais j’ai besoin qu’on puisse ensuite (en 2ème partie) se concentrer entre ceux qui veulent travailler sur subsquid

ManUtopiK · 12 February 2022 18:54

Salut. Je ne pourrais pas être là à 18h. Je vais faire mon max pour être là le plus tôt possible…

elois · 13 February 2022 16:13

@ManUtopiK ok on peut reporter, si c’est bon pour @1000i100 , que dites-vous de 19h ?

1000i100 · 13 February 2022 16:48

Va pour 19h, un lien pour la visio ?

elois · 13 February 2022 16:50

@ManUtopiK @1000i100 et les contributeurs techniques intéressés par squid, RDV à 19h ici:

ManUtopiK · 13 February 2022 17:20

Je suis là ! Merci de m’avoir attendu

elois · 13 February 2022 20:41

Je viens de commiter l’indexation des DU que j’avais ajouté en live, j’en au profité au préalable pour mettre à jour subsquid afin de pouvoir bénéficier de la nouvelle directive @index qui permet d’indexer selon le champ de son choix.

Du coup on peut enfin avoir les DU entre 2 blocs

ManUtopiK · 13 February 2022 21:04

Pas besoin de 2 explorateurs graphiQL en fait !
Avec les “remote schemas”, on peut avoir le schema de squid dans le schema de l’indexer :

https://5d08-86-250-213-140.ngrok.io/graphql est le endpoint de mon squid, mis dans un pipe ngrok : ngrok http 4350.
L’indexer et squid ne sont pas dans le même container. Il y a peut-être moyen de passer par le network du docker-compose… Je suis passé par ngrok pour faire vite.

Résultat : le endpoint de l’indexer présente les 2 apis :

C’est mal de faire ça ?
Je n’ai pas bien saisi l’intérêt de l’indexer je pense. Juste dispatcher sur des squids en microservices ?
Si l’indexer doit rester privée, pourquoi ce n’est pas squids qui contient Hasura ?
Ce serait plus logique d’utiliser Hasura en front (pour profiter des actions, remote schemas, events, cache…) plutôt que l’api de squid construite avec typeorm. De plus, la console d’Hasura est pas trop mal (pas complètement nocode, mais ils y travaillent je crois) pour créer des tables, ajuster les permissions et créer des relationships entre les tables.

Si je veux un nœud pour créer ma propre logique applicative, je vais certainement devoir créer des tables. Hasura permet de créer des relations graphql avec des remotes schemas.
Par ex, je créé une table products dans Hasura :

id: uuid!  # primary key de ma table products
createdAt: timestamp!
...
ownerId: ID! # id substrate d'un account

En ajoutant la relation accountById.id = products.ownerId, on injecte le type account de squid dans le type owner de notre table. Et on peut faire une requête graphql :

query products {
    id
    createdAt
    ...
    owner {
       id
       balance
       historicalBalances
    }
}

Ainsi en une requête, je liste mes produits avec les données de la ğ1 de chaque propriétaire de mes produits. C’est carrément plus simple !

Bon, il faut que je prenne le temps de comprendre tout ça un peu mieux. Mais l’intégration d’Hasura dans la stack est bizarre je trouve…

elois · 13 February 2022 21:16

A priori non, mais je ne pense par que ce soit utile

L’indexer indexe en brut les blocs substrate dans un format commun quel que soit le processeur. Ça permet de scalabiliser car c’est la partie la plus gourmande en traitements.
Ça permet que chaque processor puisse accéder à des données “pré-traitées”.

L’indexer peu être public, et c’est bien qu’il y ai des indexers public, ça permet de pouvoir coder un processor sans avoir besoin de setup un indexer en local.

Désolé pas compris la question, après le mieux c’est peut-être que tu leur poses tes questions ici: Issues · subsquid/squid-sdk · GitHub

Il me semble qu’en faisant ça on perdrait de nombreux avantages de subsquid, il est même possible que le processor ne fonctionne plus. Le mieux serait d’en discuter avec les dev de subsquid pour voir s’il est possible de concevoir un moyen d’exposer les fonctionnalités de Hasura

Après ce n’est parce que Hasura permet bien plus qu’on ait obligé d’y utiliser, subsquid semble déjà répondre à la majorité de nos besoins en l’état (si ce n’est la totalité)