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 ?