### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [23 February 2024 21:15 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/1 "2024-02-23T21:15:53Z")
Suite aux discussions récentes sur le fil [Duniter-squid - #41 by poka](https://forum.duniter.org/t/duniter-squid/11858/41) et à la MR [!16](https://git.duniter.org/nodes/duniter-squid/-/merge_requests/16), je pense qu’il est bon de prendre un peu de recul sur les raisons des choix de stack.
Le premier indexeur `duniter-indexer` réalisé par @ManUtopiK et aujourd’hui [archivé](https://git.duniter.org/nodes/duniter-indexer/) est né alors que squid n’était pas du tout mature, notamment suite à une discussion (2022-02-22) qui a suivi un ticket subsquid :
>
>
> Hi!
> We are currently rebuilding a French blockchain with Substrate, and I would… like to use squid to expose a custom graphql API on top of it. I'm new to substrate and just discovered squid, so sorry if my issue looks naïve. However, I've been working with Hasura since tree years, so I'm really enjoyed to see it in your stack!
>
> I read in your doc :
> \> Subsquid is rapidly deploying Archives to gather data from available blockchains on behalf of developers who wish to use this data to develop DApps.
>
> So, I don't understand why Hasura is on the top of the indexer (Archive)?
> The main purpose of Hasura is to build App fast. I need actions, schema remote stitching, events/cron and row/column level permission provided by Hasura to build my awesome DApp. Why Hasura is on the indexer and not a part of the squid api?
>
> Also, we don't need an ORM with Hasura. Hasura is an ORM on top of database!
> Why using typeorm in squid to build the graphql api when Hasura could do that out of the box?
> Hasura can also build a graphql endpoint on top of many databases. Why not connecting directly the squid database in Hasura? \`squid/graphql-server\` is useless!
> I certainly don't understand well the squid stack, but it seems you are missing out many killer features of Hasura...
>
> Anyway, for now, I used "remote schema" to merge the squid api in Hasura. By this way, I don't have to go to the squid graphiql at port 4350. I just go to Hasura at localhost:4010/console and I got the indexer and squid api merged together. By this way, we can imagine many squid running as microservices, and got one endpoint to fetch them all...
>
> !\[image\](https://user-images.githubusercontent.com/188172/153781705-b2676370-65b5-4664-bda5-ae7ef63d04d0.png)
discussion que j’ai illustrée ainsi :
> [@Subsquid (ancienne Hydra): indexer de blockchain substrate exposant des API GraphQL](https://forum.duniter.org/t/subsquid-ancienne-hydra-indexer-de-blockchain-substrate-exposant-des-api-graphql/9074/28):
>
> 
>
> Bon alors, quand est-ce qu’on reprend la battle 😃
Cette preuve de concept étant le premier indexeur disponible pour Duniter-v2, il a naturellement été intégré aux clients Ğecko et Ğcli.
Plus tard, motivé par les mêmes besoins qu’elois d’avoir un indexeur substrate générique
> [@Subsquid (ancienne Hydra): indexer de blockchain substrate exposant des API GraphQL](https://forum.duniter.org/t/subsquid-ancienne-hydra-indexer-de-blockchain-substrate-exposant-des-api-graphql/9074/30):
>
> 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](https://hydra.gdev.librelois.fr/console)
>
> Ça me servait pour debugger, pour savoir ce qu’il s’est passé quand 🙂
j’ai tenté de reprendre l’indexeur Hydra que j’utilisais aussi, mais comme ça ne marchait pas et qu’entre temps Hydra était devenu Subsquid, je me suis lancé dans un indexeur subsquid (sans voir [le dépôt](https://git.duniter.org/tools/duniter-squid) de elois)
- 2023-11-20 je crée un dépôt d’après le tutoriel squid
- 2023-11-22 j’ajoute les composants de “giant squid” pour avoir accès à une indexation générique
- à ce stade, **j’avais ce qu’il me fallait** : de quoi débugger la blockchain avec une indexation de tous les blocs, extrinsics, calls et événements, mais j’ai décidé de **pousser l’expérience un peu plus loin** pour voir où ça me mènerait
- 2023-11-26 en quelques jours de travail, j’arrive à un indexeur aussi complet que duniter-indexer et
- sans les bugs de duniter-indexer
- avec des types typescript entièrement dérivés des metadata du runtime
- avec la gestion des blocs non finalisés et du rewind des forks BABE
- avec de bien meilleures perspectives de développement (notamment runtime upgrades)
- mais avec quelques limitations liés à des choix discutables de subsquid
- un bug de typeorm qui empêche de checker la null safety [#228](https://github.com/subsquid/squid-sdk/issues/228) (légèrement gênant mais on peut vivre avec)
- l’impossibilité de choisir des primary key qui ne soient pas des string (légèrement gênant également, mais pas dramatique)
Il m’est donc apparu clairement que squid était la direction à prendre, et je suis encore entièrement de cet avis. Entre temps, @poka s’est fait la main sur squid (janvier 2024) et a entrepris d’implémenter des fonctionnalités plus ambitieuses (février 2024) avec une fonction SQL pour les DU par membre. Ce faisant, il a découvert des limites de squid :
- l’absence de sécurité par défaut contre des requêtes graphql malicieuses (aspirer la base de données entière ou des récursions infinies) dans le processeur graphql (alors que Hasura a ça par défaut)
- la prise en charge limitée des requêtes SQL custom dans l’overlay graphql (alors que Hasura fait ça par défaut)
- les fonction de paginations moins avancés que l’API relay de Hasura (beta)
- (à completer si j’ai oublié quelque chose, mais il me semble que c’est les deux plus gros points)
Et donc tout feu tout flamme (en même temps c’est poka 🔥 💙 ❤ ), il s’est lancé dans l’intégration de Hasura à duniter-squid pour obtenir le meilleur des deux mondes (21-22-23 février). (je vois ça en direct parce que poka bosse chez moi en ce moment).
Mais là on se frotte à deux logiques contraires :
- d’une part squid part d’un schéma annoté et en déduit les types orm et la structure de la base de données
- d’autre part Hasura part de la structure de la base de données et en déduit un schéma graphql
Il n’est donc pas évident de savoir qui doit gérer les migrations de la base de données, et comment profiter du meilleur des deux mondes sans subir de conflits. Pour réfléchir à cette question, voici les points qui me semblent importants :
- garder le contrôle sur le schéma sans que cela soit trop complexe (confort des devs de clients)
- conserver une définition de la base de données sans action manuelle (charge de travail et homogénéité)
- pouvoir remplir la base de données avec des typeorm, donc sans sql (confort et vitesse de développement)
- se passer de l’écriture du résolveur graphql pour les requêtes sql custom (complexité et source de bugs)
- profiter d’une sécurisation par défaut sans action manuelle (l’API principale ne doit pas être fragile)
Trouver la bonne architecture pour répondre à ces contraintes peut prendre un peu de temps, donc je pense qu’il faut éviter de se lancer tête la première dans l’intégration de Hasura coûte que coûte de manière prématurée.
~~J’invite les développeurs de clients à se fier au schéma actuel, que l’on doit encore compléter et stabiliser. De mon côté je vais essayer de trouver une autre approche pour intégrer Hasura à duniter-squid qui permette de conserver le contrôle sur le schéma. @poka il faut qu’on discute des priorités sur duniter-squid et les datapods, à mon avis intégrer Hasura de cette façon est un peu prématuré, conceptuellement on pourrait même le faire après la migration sans trop de problème.~~
Bon, c’est pas clair, on va peut-être trouver la solution plus vite que prévu.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 March 2024 12:11 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/2 "2024-03-05T12:11:09Z")
Quand @poka était chez moi, il a bossé toutes les nuits pour arriver au bout de la migration Hasura. Quasiment tout est en place, voici ce qu’il manque :
- **la pagination par curseur**
celle-ci est gérée dans une API beta dans Hasura, et un bug empêche de combiner la limitation de nombre de résultat et un curseur allant au delà de cette limitation. Il faut donc utiliser la pagination par offset qui est moins pratique
- **la non-nullabilité de certaines relations**
à cause d’une limitation de typeORM qui empêche de pousser un objet avec des relations non nullables, la structure de la base de données ne peut pas assurer la non nullabilité de ces champs. Jusque là le schéma n’était pas altéré et le problème était caché sous le tapis, mais comme Hasura déduit le schéma de la structure de la base de données, le problème refait surface. En pratique, ça consiste à ajouter un `!` ou un `.unwrap()` côté client plutôt que de cacher le problème côté serveur. Embêtant mais _a priori_ pas gênant.
- **les enum**
dans le moteur graphql de squid, les enum n’étaient pas gérées directement dans la base de données mais par le résolveur. On a donc actuellement des string en base de données qui ne sont pas des enums, et donc ça apparaît dans le schéma graphql. Valable pour le IdentityStatus, le SmithStatus, et le EventType. Pas dramatique mais léger manque de confort pour les devs de clients.
Pour l’instant :
- l’instance [https://subsquid.gdev.coinduf.eu/graphql](https://subsquid.gdev.coinduf.eu/graphql) est en Squid
- l’instance [https://gdev-squid.axiom-team.fr/](https://gdev-squid.axiom-team.fr/) est en Hasura
Il reste à adapter les clients, à commencer par Ğcli. Dès que celui-ci est adapté pour Hasura, je mets à jour mon instance. En attendant Cesium-v2 peut utiliser l’instance Axiom.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 March 2024 15:29 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/3 "2024-03-05T15:29:37Z")
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](https://git.duniter.org/clients/rust/gcli-v2s/-/merge_requests/26).
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](https://git.duniter.org/nodes/duniter-squid/-/commit/50c8b5613ac152ba298577de49e18323dc476e64)
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.
* * *
> [@Squid pour Duniter, épisode 2](https://forum.duniter.org/t/squid-pour-duniter-episode-2/11713/25):
>
> integrating hasura should be very straightforward
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.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 March 2024 18:20 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/4 "2024-03-05T18:20:28Z")
Il manque aussi une fonctionnalité essentielle pas encore intégré à la version hasura:
```bash
curl -s -H "Content-Type: application/json" -d '{"query":"{ galuel }"}' https://subsquid.gdev.coinduf.eu/graphql | jq -r '.data.galuel'
```
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 March 2024 20:07 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/5 "2024-03-05T20:07:42Z")
> [@poka](#):
>
> 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.
Je vois pas pourquoi ce serait mieux d’adopter une représentation string qui commence par `0x` plutôt que `\\`. Pas besoin de se faire chier côté serveur pour remplacer deux caractères qu’on ignore de toute façon côté client. Ce qui suit reste une représentation hexadécimale, il n’y a rien à parser.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 March 2024 20:33 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/6 "2024-03-05T20:33:51Z")
Parceque
- Certaines lib interprêtent le 0x des string et les traitent alors automatiquement comme de l’hexa
- C’est une convention largement répandu
Mais si ça s’avère trop compliqué a traiter, alors je laisse tomber.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 March 2024 21:12 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/7 "2024-03-05T21:12:59Z")
Et est-ce que tu as une idée de pourquoi Hasura nous sérialise ça sous forme de string en `\\x` ? Est-ce qu’on peut le paramétrer pour changer la sérialisation ?
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 March 2024 21:19 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/8 "2024-03-05T21:19:27Z")
Justement je n’ai pas trouvé comment faire (encore).
C’est dû au fait qu’en DB les champs hash sont des bytea, car déclarés comme Bytes dans le schema graphql. Il tente d’échapper les caractères spéciaux à la lecture de la string via l’API, car ce sont êtres des bytes normalement.
Hors, c’est bien du format hexa qui est stocké, donc en réalité c’est le format Bytes du schema graphql qui est a remettre en question.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [5 March 2024 21:43 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/9 "2024-03-05T21:43:39Z")
> [@poka](#):
>
> c’est bien du format hexa qui est stocké
~~Ah oui, je savais pas. C’est ça qui est con, tu as raison. Encore une connerie de squid. Stocker des bytes comme des string, c’est étrange.~~
[edit] comme tu dis :
> [@poka](#):
>
> les hash sont bien converties en bytes
Au cas où je t’ai mis un exemple de déserialisation dans ta branche. [edit: gcli]
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 March 2024 21:47 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/10 "2024-03-05T21:47:13Z")
Je me suis pas encore repenché dessus je vais ptetre reprendre là et explorer ça, merci 🙂
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [5 March 2024 22:22 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/11 "2024-03-05T22:22:54Z")
J’ai réfléchi à ce problème de curseur, et de profondeur d’arbre de subsquid. J’aimerai qu’on en reparle tous ensemble au RML18, car j’aimerai comprendre plus en détail les limitations, et voir un peu d’avantage le code… Avoir aussi l’avis de cgeek.
@poka tu serais prêt pour une démo + explication de code ?
En particulier les limitations et l’écriture de resolver, pour subsquid.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [5 March 2024 22:48 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/12 "2024-03-05T22:48:18Z")
> [@kimamila](#):
>
> En particulier les limitations et l’écriture de resolver, pour subsquid
Voici le resolver squid pour l’historique des DU par comptes: [src/server-extension/resolvers/du\_history\_resolver.ts · c44964da9d8858d03253a3ddfbbfe9e2333135c6 · nodes / duniter-squid · GitLab](https://git.duniter.org/nodes/duniter-squid/-/blob/c44964da9d8858d03253a3ddfbbfe9e2333135c6/src/server-extension/resolvers/du_history_resolver.ts)
Il n’est donc plus présent sur la version Hasura car généré automatiquement par ce dernier.
La requête SQL utilisé pour ce resolver: [src/server-extension/sql/du\_history\_query.sql · c44964da9d8858d03253a3ddfbbfe9e2333135c6 · nodes / duniter-squid · GitLab](https://git.duniter.org/nodes/duniter-squid/-/blob/c44964da9d8858d03253a3ddfbbfe9e2333135c6/src/server-extension/sql/du_history_query.sql)
C’est la même requête SQL renseigné comme computed field dans Hasura.
Il n’y a pas de limitations particulière, dans un cas comme dans l’autre. Simplement dans le cas de squid, la nécessité de ré-implémenter les clauses conditionnelles, les limites, offset, en SQL, avec son parsing TS côté resolver.
Pour la demo, les instances sont déjà en ligne et rappelé par Hugo juste au dessus.
Je veux bien faire des explications de codes si nécessaire, mais je ne compte rien prévoir de ce côté là, je pourrais répondre aux questions.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [6 March 2024 01:22 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/13 "2024-03-06T01:22:04Z")
> [@poka](#):
>
> c’est bien du format hexa qui est stocké
J’ai parlé un peu vite, les hash sont bien converties en bytes (Buffer) (sans quoi ça ne pourrais pas être stocké dans un champ sql bytea…)
```auto
export function decodeHex(value: string): Buffer {
assert(isHex(value))
return Buffer.from(value.slice(2), 'hex')
}
```
Je suis étonné que l’API ne nous affiche pas un Uint8Array du coup.
Du coup en local, en stockant les hash en string c’est sûr que ça ressort bien en hexa
```auto
{
"data": {
"block": [
{
"id": "0000158019-2c002",
"height": 158019,
"hash": "0x2c002dd9c261ada90f34b1478a559edc42db525a15f829659f2f1e454f547488"
}
]
}
}
```
Mais bon on perds gros en optimisation de stockage (32 octets contre 66 octets par hash), quand on compte 3 hash par block + les hash d’extrinsics, et 1 blocs toutes les 6 secondes, ça grimpe très vite. Sans comptez les perfs de calcule sur du binaire comparer à des strings pour les tries et conversions graphql.
Il s’agit donc d’une simple différence de sérialisation. Postgre sérialise les chaines bytea en hexa avec `\x`, là où en générale ailleurs, on sérialise avec `0x`. Ce sont en fait 2 conventions hexa (je ne connaissais pas celle de postegres). Le format JSON échappe le caractère `\` avec `\`, ce qui donne `\\` (passionnant hein?)
Je regarde un peu si on peut facilement changer cette serialization côté postgres ou hasura, mais je crois que c’est compromis.
Une issue est ouverte à ce sujet, qui en référence une autre: [Return `bytea` hex values without `\\x` prefix · Issue #48 · bitauth/chaingraph · GitHub](https://github.com/bitauth/chaingraph/issues/48)
Mais branche ajoute de la lourdeur non nécessaire, donc on va rester comme ça sur ce point je pense.
Sinon on peut aussi forker Hasura pour résoudre le ticket #48…
* * *
Sinon en résultat ça donne ça, les champs hash, mais avec Hex devant:
```auto
query MyQuery {
block(limit: 1, orderBy: {height: ASC}) {
hashHex
parentHashHex
stateRootHex
validatorHex
}
extrinsic(limit: 1, orderBy: {index: ASC}) {
hashHex
}
}
```
→
```auto
{
"data": {
"block": [
{
"hashHex": "0xc184c4ccde8e771483bba7a01533d007a3e19a66d3537c7fd59c5d9e3550b6c3",
"parentHashHex": "0xc184c4ccde8e771483bba7a01533d007a3e19a66d3537c7fd59c5d9e3550b6c3",
"stateRootHex": "0xc184c4ccde8e771483bba7a01533d007a3e19a66d3537c7fd59c5d9e3550b6c3",
"validatorHex": "0xc184c4ccde8e771483bba7a01533d007a3e19a66d3537c7fd59c5d9e3550b6c3"
}
],
"extrinsic": [
{
"hashHex": "0x2c3a488a9b4053b938745ca5114372db78153d3ebff9c094b05dcac34713d2f5"
}
]
}
}
```
J’ai tourné le truc dans tous les sens, le code le plus generic que j’ai pu faire est ce commit: [add computed fields for all hash (!18) · Merge requests · nodes / duniter-squid · GitLab](https://git.duniter.org/nodes/duniter-squid/-/merge_requests/18/diffs)
Ca juste juste pour remplacer `\\` par `0`… Aller j’arrête.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [8 March 2024 18:41 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/14 "2024-03-08T18:41:31Z")
> [@HugoTrentesaux](#):
>
> les enum
Sont maintenant intégrés via la [MR!19](https://git.duniter.org/nodes/duniter-squid/-/merge_requests/19).
En prod sur [https://gdev-squid.axiom-team.fr/v1/graphql](https://gdev-squid.axiom-team.fr/v1/graphql)
Il reste donc ces deux points gênants, mais non bloquants:
> [@HugoTrentesaux](#):
>
> - **la pagination par curseur**
> celle-ci est gérée dans une API beta dans Hasura, et un bug empêche de combiner la limitation de nombre de résultat et un curseur allant au delà de cette limitation. Il faut donc utiliser la pagination par offset qui est moins pratique
> - **la non-nullabilité de certaines relations**
> à cause d’une limitation de typeORM qui empêche de pousser un objet avec des relations non nullables, la structure de la base de données ne peut pas assurer la non nullabilité de ces champs. Jusque là le schéma n’était pas altéré et le problème était caché sous le tapis, mais comme Hasura déduit le schéma de la structure de la base de données, le problème refait surface. En pratique, ça consiste à ajouter un `!` ou un `.unwrap()` côté client plutôt que de cacher le problème côté serveur. Embêtant mais _a priori_ pas gênant.
- Issue pagination par curseur: [Limit number of rows parameter shouldn't be limiting with pagination using relay API · Issue #9578 · hasura/graphql-engine · GitHub](https://github.com/hasura/graphql-engine/issues/9578)
- Issue nullsafety typeORM: Je n’en ai pas sous la main, mais c’est confirmé par les devs de squid. Il faudrait tout de même linker une issue.
- Je rajoute cette issue qui est une feature à améliorer: [Return `bytea` hex values without `\\x` prefix · Issue #48 · bitauth/chaingraph · GitHub](https://github.com/bitauth/chaingraph/issues/48)
Au final, je trouve que cette intégration Hasura nous offre plus de contrôle sur les migrations squids, et la config graphql.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [9 March 2024 07:11 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/15 "2024-03-09T07:11:44Z")
Merci @poka pour ce travail d’analyse et de réalisation sur l’indexeur.
Tu coup, j’aimerais bien aussi avoir une visualisation des tables du schéma utilisé par squid, lors des RML.
Je ne trouve pas le resolver UD history très complexe, comparativement a d’autres projets graphql que j’ai vu, et qui tourne bien (en production).
Par ailleurs, après avoir expérimenté les curseurs, je leur trouve énormément d’intérêt. Par exemple côté App, la gestion de l’historique des transactions via offset devient vite complexe, dès qu’on veut ajouter du cache. Cela vient du fait que la réponse a un même offset n’est pas invariant. Pour avoir une réponse invariant il faut jouer sur les paramètres de la requête, et filtrer sur une période fixe (blockTime \< t1).
Bref, comme hasura a aussi des limitations de son côté je serai assez motivé (avant d’en discuter au RML) pour continuer de creuser la piste subsquid sans Hasura qu’avait débuté @HugoTrentesaux. Rien que pour les curseurs ça me semble valoir le coup.
En fait ce que je sais pas c’est si cela serait compliqué de limiter la profondeur de la requete nous même. Je dois creuser.
L’avis de @cgeek n’intéresse aussi fortement car il connaît bien typescript. Par ailleurs je penses que l’indexeur fait partie du noyau de Duniter : car rien ne peut être fait sans lui. C’est en quelque sorte le remplaçant de BMA / GVA. Il faut donc que les développeurs du noyau donne leur expertise, dans la mesure du possible.
L’impact des changements actuels de l’API de l’indexeur n’est pas négligeable. Pour être clair je dois réécrire une bonne partie de Cesium2… Alors que j’étais très satisfait jusque là de la forme des requêtes.
Voilà, désolé @poka d’être moins emballé que vous par Hasura… Mais c’est pourquoi on doit en parler (calmement si possible 🙂 ) de visu. Cela lèvera peut-être mes réticences.
Merci de m’avoir lu.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [9 March 2024 09:06 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/16 "2024-03-09T09:06:41Z")
> [@kimamila](#):
>
> L’impact des changements actuels de l’API de l’indexeur n’est pas négligeable. Pour être clair je dois réécrire une bonne partie de Cesium2… Alors que j’étais très satisfait jusque là de la forme des requêtes.
Si tu savais le nombre de refonte que j’ai dû faire sur Ğecko en 2 ans… J’ai commencé sur GVA, qui a changé X fois. D’abords en binding rust, puis ma lib Durt. Ensuite v2s, passage sur la lib polkawallet-sdk, avec webview et tout ce que cela induit. Et là je m’apprête à changer de nouveau, car j’ai le feu vert des dev de la lib pure dart: [Project Status · Issue #433 · leonardocustodio/polkadart · GitHub](https://github.com/leonardocustodio/polkadart/issues/433)
Et il faut que je migre mes requêtes de l’indexer v1 à l’indexer squid aussi.
A chaque je n’avais pas le choix, c’était réfléchie, rien n’indiquait que j’aurais du changer de telle sorte, avant même la mise en prod du réseau.
Je comprends que c’est embêtant, mais vue que c’était quelque chose que nous projetions dès le début de l’arrivé de squid, j’ai voulu le faire suffisamment tôt (avant la migration) pour ne pas s’enfoncer trop profondément dans le moteur graphql de squid justement.
> [@kimamila](#):
>
> Je ne trouve pas le resolver UD history très complexe, comparativement a d’autres projets graphql que j’ai vu, et qui tourne bien (en production).
Oui le resolver est simple en soit, mais par exemple je n’ai pas traité toutes les clauses where possibles, juste les principales (pas sûr que les autres auaient été utiles hein).
Et peut être qu’a l’avenir nous voudrons ajouter d’autres computed fields, avec peut être des resolvers plus complexe. Avec Hasura cette ajout est une formalité une fois qu’on a la bonne requête SQL.
Aussi, Hasura nous offre les requêtes aggregates, que je trouve très pratique.
Au niveau des changements, je l’ai est effectué dans gcli, c’était très rapide. C’est certains pluriels qui sont passé infinitif, et les `eq` et ce genre de clause imbriqués au lieu de collé à la clause par `_` (ce que je trouve beaucoup plus claire et logique personnellement).
Ensuite oui le gros point c’est le pagination par curseur.
A savoir qu’en utilisant l’API relay, actuellement cette pagination par curseur fonctionne sans bug étant donnée qu’aucune limite de requête n’a été définit par table (pour le moment). Le bug est juste quand cette limite est définit, la somme des lignes retourné par la requête paginé est limité par cette valeur (ex: 10 pages x 100 lignes max si la limite est fixé à 1000 ligne pour cette tables, même si il y a 50000 lignes au total à requête). C’est pourquoi dans gecko on ne pouvait pas remonté l’historique des transactions jusqu’au début pour les gros historique dans l’indexer Hasura de manu.
Donc on peut aussi décider de ne pas fixer de limite de ligne par table pour pouvoir utiliser la pagination par curseur de l’api relay hasura (qui est dispo dès à près en, voir le switch dans la console Hasura pour voir le endpoint est le requêtes), et de fixer ces limites autrement.
Au moins même sans limites, je n’ai pas réussi à faire crasher le moteur graphql de Hasura même avec d’énorme requêtes, juste une très longue attente côté client. Alors qu’avec le moteur graphql de squid, un peu trop de lignes, et c’est tchao, il crash, faut le rebooter.
* * *
Je ne suis pas du tout contre l’idée de finalement garder le moteur graphql de squid, je considère qu’on ne pouvais pas trancher sans aller à fond dans l’implémentation Hasura pour en voir clairement les contours, et donc trancher en connaissances de cause.
Mais il faut peser les pour et les contres
> [@kimamila](#):
>
> calmement si possible 🙂
Toujours 🙂 🔪
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [9 March 2024 14:50 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/17 "2024-03-09T14:50:57Z")
Merci pour ta réponse, ouverte, que j’apprécie 🙂
En regardant la doc subsquid, je tombe la dessus : [DoS protection | Subsquid](https://docs.subsquid.io/sdk/resources/graphql-server/dos-protection/)
Du coup, je me dis que l’on devrait pouvoir limiter de manière precise la taille des flux de retour. Et même écrire des tests unitaires pour vérifier nos réglages, par exemple en repartant des cas de plantage que tu obtenu ?
Leur approche me paraît assez propre.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [9 March 2024 14:54 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/18 "2024-03-09T14:54:22Z")
Si la limitation par @cardinality ne suffit pas, nous pourrions aussi utiliser leur système de control d’accès, en analysant la portée et profondeur de grappe de la requête, suivant nos critères, puis renvoyer une erreur “not allowed” le cas échéant.
> **[Access control | Subsquid](https://docs.subsquid.io/sdk/resources/graphql-server/authorization/)**
>
> Authentication and authorization
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [9 March 2024 20:21 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/19 "2024-03-09T20:21:52Z")
Oui c’est ce que j’expliquais ici dans ce ticket : [Define @cardinality for every type in graphql.schema (#12) · Issues · nodes / duniter-squid · GitLab](https://git.duniter.org/nodes/duniter-squid/-/issues/12)
Et dans le topic de forum associé.
Je trouve que la définition de ces cardinalités alourdissent le schema.graphql pour rien, et le complexifie.
Mais tu peux rouvrire le ticket si tu veux.
Hasura ne nous apporte pas que ce genre de chose, il nous permet un plus grande souplesse dans le schema graphql via ses metadata.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [10 March 2024 18:26 UTC](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018/20 "2024-03-10T18:26:11Z")
> [@kimamila](#):
>
> l’indexeur fait partie du noyau de Duniter : car rien ne peut être fait sans lui.
C’est ce que je pense aussi, c’est ce qui m’a motivé à m’y mettre fin 2023 et ça va donc être un gros sujet de discussion pour les RML.
> [@kimamila](#):
>
> je dois réécrire une bonne partie de Cesium2
Normalement non, la forme des requêtes ne change que légèrement entre squid sans et avec Hasura, et la forme des réponses est quasiment identique (uniquement l’histoire de null safety je pense, qui est une limitation de typeorm et pas de hasura).
> [@kimamila](#):
>
> une visualisation des tables du schéma utilisé par squid, lors des RML.
L’intérêt de squid et de typeorm est qu’on n’a jamais à définir manuellement les tables (d’où certaines limitations), vu que la seule chose à définir est le schéma. Et le schéma qu’on définit est extrêmement simple, il tient en gros sur [150 lignes](https://git.duniter.org/nodes/duniter-squid/-/blob/main/schema.graphql?ref_type=heads#L139-L283), ce qui va rendre les discussions intéressantes puisqu’on pourra tous facilement rentrer dans le vif du sujet.
Hâte d’y être pour pouvoir échanger dessus.
[Next page](https://forum.duniter.org/t/hasura-hydra-squid-un-peu-de-recul-simpose/12018.md?page=2)