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

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

1 Like

Va pour 19h, un lien pour la visio ?

1 Like

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

1 Like

Je suis là ! Merci de m’avoir attendu :slight_smile:

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 :partying_face:

1 Like

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…

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

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 :sweat_smile:

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é) :slight_smile:

C’est surtout que je ne comprends pas à quoi sert Hasura dans la stack ? (surtout si c’est pour ne pas l’utiliser)

De ce que j’en comprends, il semble qu’ils s’en servent uniquement pour générer l’API graphql à partir de la base postgres.

1 Like

Nan mais franchement, je persiste à penser qu’elle est montée à l’envers leur stack. Comment ils se font chier pour rien ! Ou alors j’ai rien compris au but de subsquid !?
Le message est dans la Porche et ils ont mis un camion dessus pour faire Paris-Brest :slight_smile:
J’ai posté une issue et on me répond que « Squid API is designed to be lightweight » !

J’essaye de comprendre l’architecture de tout ça pour comprendre ce que je fais. Et comme je débarque juste, j’ai pas envie de raconter trop de conneries en leur disant qu’ils pourraient jeter en l’air 6 mois de boulot !

Je m’explique. Voilà leur schéma :

Hasura est avec l’Archive alors que ça aurait été 1000x mieux de s’en service pour la Gateway.

Regarde, ils se font chier pour rien : ils utilisent typeorm pour le processor afin d’écrire les données dans sa DB postgres, et pour la gateway (avec apollo-express) pour créer le endpoint graphql public.
Qu’ils utilisent typeorm entre le processor et la gateway est normal. Mais ils s’en servent juste pour créer un endpoint graphql. Hasura fait déjà ça en 1000x mieux ??? Il y a pas besoin de typeorm ni d’apollo ni d’express !
C’est lightweight ou pas ?

En plus, ça expose un endpoint graphql pas protégé !

J’arrive à planter le squid de la blockchain khala :slight_smile:
Tu entres une requête sans limite et ça plante :

query MyQuery {
  substrate_block {
    id
  }
}

Avec hasura, tu peux lui dire de mettre une limite max par rôle (admin, user, public) et tu peux créer les rôles que tu veux, il y a un ratelimiter, un limiter de requêtes n+1, un cache… Là, la gateway n’a rien de tout ça !

Pour moi ils se sont plantés. Hasura est avec l’Archive alors que ça aurait été 1000x plus simple et bénéfique de s’en servir pour la Gateway.

Le but de subsquid est bien de collecter des données en blockchain et créer une api facile pour faire des DApps, non ?

3 Likes

De mon côté je ne connais pas Hasura, j’ai juste étudié la liste de tout les indexers substrate proposées, et j’ai retenu subsquid car c’est le seul qui permet de customiser facilement quelles données on veut indexer et de définir comment on veut les présenter.

Je viens de lire l’issue que tu as ouverte et la réponse très détaillée de l’un des développeurs de subsquid, il me semble qu’il liste bien pourquoi ils n’utilisent pas davantage Hasura:

Personnellement je suis en accord avec leur philosophie qui consiste à garder quelque chose de simple, avec une seule codebase unifiée tout en pouvant fournir des fonctionnalités avancées comme la recherche fulltext.

Je suis certain que subsquid est perfectible (comme tout…), et je suis certain également qu’avec ton expertise sur Hasura tu peux leur apporter des précieux conseils qui peuvent les aider à améliorer subsquid, ils sont également très à l’écoute des besoins de leurs utilisateurs :

I’m genuinely interested in your use-case and would be happy to discuss more in TG – feel free to ping me @dzlzv on Telegram.

Pour le moment subsquid répond à tous mes besoins, si j’identifie des besoins auquel il ne répond pas je leur en ferais part :slight_smile:

1 Like

Je peux me planter, mais de ce que je comprends de la présence d’Hasura, c’est juste pour avoir une interface web pour administrer la base de données PostgreSQL.

Ayant joué un peu avec Hasura pour mon projet pro (mais j’ai finalement fait ma propre API légère GraphQL comme eux), j’ai été sidéré par la qualité de l’interface d’admin de la base de données. Je me suis dit : putain c’est la meilleure interface d’admin que j’ai vu depuis longtemps !

A confirmer, mais Subsquid n’a pas voulu dépendre d’une stack développée par une entreprise avec des objectifs généralistes DB → GraphQL. Il font leur propre implémentation légère d’un serveur GraphQL sur une base de données PosgreSQL. Elle est vraiment légère si Hasura ne sert à rien à part administrer la base de données, et que subsquid peut être déployé sans Hasura.

J’ai bien lu sa réponse, et cela montre bien qu’ils ne connaissent pas bien Hasura.
Le support JSONB est limité par ce que peut faire postgresql. Il faut utiliser mongodb pour travailler en json. Un squid ne pourra rien faire de plus, il est lui aussi limité par postgresql.
Pour du fulltext search, il suffit de créer une fonction SQL et Hasura créé le graphql en ajoutant automatiquement where, limit, order_by… et gère les relationships entre table. On peut faire pareil avec n’importe quelle view ou materialized view de postgres !

Quant à l’argument du même code base, ça ne tient pas la route ; Hasura est déjà dans la stack !
Je dis juste qu’ils l’ont mal placé, et qu’en la plaçant sur la gateway, on peut se passer de typeorm et express. Ce serait plus simple et on aurait plus de fonctionnalités !

Excuse-moi de t’embêter avec ça @elois, mais je pense que l’on peut gagner du temps et en fonctionnalités si on s’y prend bien ! Exemple avec, 2 cas d’usages :

  • Créer une notification mail à chaque virement à mon compte, comme le fait Le Sou. Avec Hasura il suffit de créer un event insert qui appel un service d’envoi de mail. Zéro ligne de code. Comment on fait avec subsquid ?
  • Je veux afficher les stats de mon compte, avec options daily, weekly,monthly… Je crée les views en postgres, et Hasura créé automatiquement l’api graphql correspondant. C’est fait en une dizaine de lignes SQL. Ou encore mieux, on utilise timescaleDB (time-series database on PostgreSQL) dont le support Hasura est excellent. On a rien à faire et encore plus de fonctionnalités pour créer des séries !
    Avec subsquid, il va falloir créer des eventHandlers pour chaque option et définir tous les types graphql…

Tu n’as pas répondu à la question :

Le but de subsquid est bien de collecter des données en blockchain et créer une api facile pour faire des DApps, non ?

Si ce n’est pas le cas, je pense que je n’ai pas bien saisi le scope de subsquid…

1 Like

C’est un indexeur, le but c’est de pouvoir exposer les données de façon à répondre aux besoins des client/wallet, donc le but c’est nous qui le définissons.

Les besoins que je vois à minima c’est:

  • Récupérer l’historique d’un compte (transfers et création de DU)
  • Rechercher des données dans le système de stockage libre
  • Fournir des statistiques

Si tu penses pouvoir faire mieux que subsquid alors vas-y go, mais il faut que ça soit déployable via docker avec une config par défaut qui juste marche, et que tu assures la maintenance dans la durée.

Subsquid n’est pas conçu de la manière qui te semble la plus pertinente, j’entends bien, mais ça fonctionne très bien et c’est activement maintenu, mon point principal est la, j’ai besoin de quelque chose qui fonctionne et qui soit bien maintenu et qui soit simple à utiliser, si je dois commencer à écrire du SQL à la main ça ne va pas le faire :slight_smile:

2 Likes

battle

Bon alors, quand est-ce qu’on reprend la battle :smiley:

1 Like

À quels besoins subsquid répond automatiquement là où hasura seul demande du travail ?

1 Like

subsquid aussi demande du travail de dev pour présentre les données comme on veut.

Sans dev, on peut héberger un indexeur subsquid qui fourni une API GraphQL générique, j’en héberge un pour la ğdev: https://hydra.gdev.librelois.fr/console

Ça me servait pour debugger, pour savoir ce qu’il s’est passé quand :slight_smile:

3 Likes

Mon compose pour l’indexeur hydra, remplacez duniter par le nom de votre service pour duniter-v2s:

version: "3.4"

services:
  indexer:
    image: subsquid/hydra-indexer:5
    restart: unless-stopped
    environment:
      - WORKERS_NUMBER=1
      - DB_NAME=indexer
      - DB_HOST=db
      - DB_USER=postgres
      - DB_PASS=*****
      - DB_PORT=5432
      - REDIS_URI=redis://redis:6379/0
      - FORCE_HEIGHT=true
      - BLOCK_HEIGHT=0 # starting block height
      - WS_PROVIDER_ENDPOINT_URI=ws://duniter:9944/
    depends_on:
      - db
      - redis
    command: >
      sh -c "yarn db:bootstrap && yarn start:prod"

  indexer-gateway:
    image: subsquid/hydra-indexer-gateway:5
    restart: unless-stopped
    depends_on:
      - redis
      - db
      - indexer-status-service
      - indexer
    ports:
      - "4010:8080"
    environment:
      - DEV_MODE=true
      - DB_NAME=indexer
      - DB_HOST=db
      - DB_USER=postgres
      - DB_PASS=*****
      - DB_PORT=5432
      - HYDRA_INDEXER_STATUS_SERVICE=http://indexer-status-service:8081/status

  indexer-status-service:
    image: subsquid/hydra-indexer-status-service:5
    restart: unless-stopped
    depends_on:
      - redis
    environment:
      REDIS_URI: redis://redis:6379/0
      PORT: 8081

  redis:
    image: redis:6.0-alpine
    restart: always
    ports:
      - "6379"
3 Likes

@poka can you setup a new hydra using this docker-compose? I will setup one too, but two is not too many for our needs.

1 Like
message caché

service "indexer" depends on undefined service db: invalid compose project

Dans le docker-compose, il y a une dépendance aux services db et redis, mais il ne sont pas définis ici. À compléter, donc.

Elois n’a pas son docker-compose entier, j’ai donc ajouté suivant ses conseils le service postgresql :

  db:
    image: postgres:12
    volumes:
      - /var/lib/postgresql/data
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: *****

Mais j’ai ceci dans les logs alors même que j’ai un noeud duniter “duniter-rpc” qui tourne sur la machine.

hydra-indexer-1    API-WS: disconnected from ws://duniter-rpc:9944/: 1006:: connection failed

Est-ce que quelqu’un qui s’y connaît un peu en conteneurisation docker peut y jeter un œil ? Ce serait pratique d’avoir cet indexeur, mais je n’ai pas tellement envie de me former à docker et à la gestion d’infrastructure.