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 
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
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
@dzlzvon 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 
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 insertqui 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 lesviewsen 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
2 Likes
Bon alors, quand est-ce qu’on reprend la battle 
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
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.