# Squid: PostGraphile as GraphQL engine instead of Hasura
**URL:** https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257
**Category:** Indexers
**Tags:** subsquid, postgraphile
**Created:** [14 August 2025 03:23 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257 "2025-08-14T03:23:30Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 August 2025 03:23 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/1 "2025-08-14T03:23:30Z")
…
Je sais que les dev de clients qui ont déjà commencé à intégrer Squid dans leurs apps ne vont pas m’apprécier sur ce coup-là.
Plus j’avance dans la customisation d’Hasura pour Squid, plus je rencontre de problèmes :
- La pagination par curseur ne peut se faire qu’au travers de l’API Relay. Du coup, dans Gecko, je n’utilise que le path `/v1beta1/relay` pour tout, par simplicité et uniformisation de toutes mes requêtes. Mais on est sur un mode bêta d’Hasura, qui est [déconseillé par l’équipe même d’Hasura.](https://github.com/hasura/graphql-engine/issues/9578)
- Les computed fields, c’est super. C’est la raison principale qui m’a poussé à remplacer le moteur GraphQL proposé par défaut par Subsquid. Ça nous permet d’ajouter relativement facilement des queries calculées à la volée, non représentatives de tables SQL statiques. Comme la liste des DU par exemple, les soldes totaux, etc.
Problème dont je viens de me rendre compte : **impossible de faire de la pagination par curseur, même en mode API Relay** , sur des computed fields (uniquement par offset donc). J’ai tout essayé, rien n’y fait.
C’est embêtant quand on sait que je viens d’ajouter la query `transferWithUd`, computed field qui merge les transfers avec l’historique des DU, donc typiquement là où on a particulièrement besoin de pagination par curseur…
- Les metadata Hasura sont très lourdes à gérer en YAML. Certaines choses sont pensées pour être gérées par leur UI admin, mais sont très complexes à automatiser. Ça se fait, mais c’est lourd.
- Les migrations Hasura rajoutent aussi une couche de lourdeur, et jusqu’à maintenant inexploitées. On peut tout à fait gérer des scripts de migration nous-mêmes si l’envie nous chante (c’est-à-dire des scripts pour éviter de devoir resynchroniser depuis zéro les indexers lors d’un changement profond du schéma de DB).
- Et surtout, ce qui a été la goutte d’eau qui m’a fait basculer, la cerise sur le gâteau : la v3 d’Hasura (on est actuellement en v2) [**n’est plus totalement open source**](https://www.reddit.com/r/graphql/comments/1k26p6s/a_warning_to_anyone_considering_hasura_v3_for) !
Leur modèle économique est devenu très douteux et, depuis le temps, je crois que nous pouvons tirer un trait sur une v3 open source et fiable pour nous.
* * *
Tout ceci m’a poussé à remplacer Hasura par [PostGraphile](https://www.graphile.org/postgraphile/).
Si certains d’entre vous connaissent, je suis preneur de vos retours.
J’explique un peu tout ça dans [le README de la branche.](https://git.duniter.org/nodes/duniter-squid/-/blob/graphile-support/README.md)
Les avantages que j’y vois :
- Beaucoup plus léger, moins de config, hot reload en mode dev.
- Un seul endpoint, plus besoin de jongler avec l’API Relay, un schéma propre avec pagination par curseur et par offset partout, par défaut.
- Les computed fields se déclarent en SQL de manière très similaire à Hasura : pas de gros changement côté back.
- Pagination par curseur pour les computed field aussi
- Plus de field fantôme généré par Hasura dû au fonctionnement des computed fields
- Potentiellement plus performant (à vérifier)
- Communauté active.
Les défauts :
- Moins de features avancées que Hasura. Pour le moment, nous ne nous servions pas des features manquantes en question.
- Pas d’interface admin contrairement à Hasura. Juste un GraphiQL public.
- Licence MIT pour le core. Des offres pro payantes pour des fonctions avancées. Pas de garantie sur la pérennité du statut open source du core, même si pour le moment rien ne laisse penser que cela pourrait changer.
En termes de changements côté client, rien d’alarmant : le path reste `/v1/graphql` comme pour Hasura. Mais le schéma de données change un peu ; en gros, c’est un mix entre l’API Relay et l’API par défaut d’Hasura, avec le meilleur des deux mondes.
Il faut donc régénérer le code et adapter vos requêtes GraphQL, mais c’est bénin. Je peux le faire pour Gecko, Cesium et Duniter Portal.
Vous trouverez le docker-compose Graphile pour la prod, prêt à l’emploi, qui intègre un script de migration depuis la version Hasura (donc pas besoin de resynchroniser votre nœud) : juste `down`, mise à jour du compose, et `up`.
Voici un endpoint qui utilise ce moteur GraphQL : **[https://gt-squid-graphile.axiom-team.fr/graphiql](https://gt-squid-graphile.axiom-team.fr/graphiql)**
J’ai fait en sorte que Hasura et Graphile puissent fonctionner en même temps sur le même nœud sans souci.
Donc le même endpoint avec Hasura si vous voulez comparer : [https://gt-squid.axiom-team.fr/v1/graphql](https://gt-squid.axiom-team.fr/v1/graphql)
Donc on peut garder ce **mode hybride** et ainsi ne **pas casser** les clients actuels, pour une **migration progressive** (même si ça me démange de dégager toutes les config Hasura, relax 🍵 ).
Ouvert à la discussion : ce que vous en pensez, contre-propositions, etc.
* * *
PS : Je tiens à préciser que je ne fais pas ça par plaisir geek de tester le dernier truc à la mode ; ça me saoule de le faire. Mais vraiment, Hasura devenait trop limitant et lourd pour moi.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 August 2025 04:14 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/2 "2025-08-14T04:14:11Z")
TL;DR
Hasura casse les couilles, remplacé par Graphile, mode hybride, pas casser, migration progressive, votre avis.
---
### Author:  [@aya](https://forum.duniter.org/u/aya)
#### Post date: [14 August 2025 13:48 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/3 "2025-08-14T13:48:48Z")
Je ne connais pas graphile mais, pour info, on a remplacé hasura par [exograph](https://exograph.dev/docs) pour [l’api](https://develop.exo.axiom-team.fr/playground) d’axiom team.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 August 2025 13:51 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/4 "2025-08-14T13:51:42Z")
Ah ok, tu peux dire un mot du pourquoi ? Mêmes raisons que moi ? Les avantages que vous voyez à exograph (je ne connais pas) ?
---
### Author:  [@aya](https://forum.duniter.org/u/aya)
#### Post date: [14 August 2025 14:01 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/5 "2025-08-14T14:01:36Z")
faudrait demander à @ManUtopiK !
A part “c’est du rust” et “pour le fun” je sais pas vraiment pourquoi on s’est lancé la dedans 😛
Je peux juste te dire que la gestion des vues n’est pas encore supportée mais qu’il propose déjà une route /mcp !
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 August 2025 14:15 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/6 "2025-08-14T14:15:10Z")
Dak
De ce que je vois d’Exograph, je note quelques inconvénients bloquants pour notre usage dans Squid :
- Licence **BSL 1.1** (non-OSI) vs **MIT** pour PostGraphile. [Voué à passer](https://exograph.dev/legal/license-info) en licence Apache2 a terme. Absence de change date, donc au bout de [4 ans maximum](https://fossa.com/blog/business-source-license-requirements-provisions-history/), donc 2029 pour la version actuelle.
- Pagination uniquement **limit/offset** , pas de cursors Relay, donc pas de pagination par curseur sur les computed fields, ni le reste (ce qui est en fait mon principal argument pour bouger de Hasura, qui propose quand même une API relay alternative).
- Pas de support des **vues** et pas de computed fields SQL natifs ; logique custom surtout via **modules Deno** (JavaScript/TypeScript côté serveur, hors Postgres).
- DX moins “DB-first” : plus de code/app à maintenir, moins plug-and-play que PostGraphile qui offre un endpoint unique, hot-reload et connections Relay y compris sur computed.
---
### Author:  [@ManUtopiK](https://forum.duniter.org/u/ManUtopiK)
#### Post date: [14 August 2025 16:04 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/7 "2025-08-14T16:04:01Z")
Génial @poka !
Oui, la direction que prend Hasura ne me plait pas du tout : hasura ddn ou promptql…
Et je le disais déjà depuis l’indexer fait maison, Hasura n’a pas de rate limiter ni de grapql depth query limit.
J’ai découvert Exo il y a quelques mois et j’ai bien aimé le concept : écrit en Rust, postgres en wasm pour les tests, deno embarqué !, interceptors pour rate limite…
Du coup, pour axiom-team, vu que l’on avait que 3 tables et pas trop de contrainte sur l’api, on a migré sur Exo.
Mais le projet est encore jeune, et il manque pas mal de truc (api relay, constraint on mutation, api sur les vues et functions (mais pas impossible)…).
Sinon, c’est très DB first. Un simple `exo schema create` créé le fichier .exo depuis le schéma d’une bdd.
J’avais testé PostGraphile il y a 4-5 ans et j’avais trouvé l’implémentation beaucoup plus complexe que Hasura à l’époque. Aussi, la version open source n’a pas de rate limiter non plus. Il faut passer à la version payante 25€/mois…
---
### Author:  [@ManUtopiK](https://forum.duniter.org/u/ManUtopiK)
#### Post date: [14 August 2025 16:12 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/8 "2025-08-14T16:12:50Z")
Le hot-realaod sur exo est juste magique. Tu as testé leur [Playground | Exograph](https://exograph.dev/playground) ?
Tu as exo, postgres en wasm et graphiql sur la même page !
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 August 2025 16:31 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/9 "2025-08-14T16:31:25Z")
> [@ManUtopiK](#):
>
> J’avais testé PostGraphile il y a 4-5 ans et j’avais trouvé l’implémentation beaucoup plus complexe que Hasura à l’époque
En tout cas si tu regardes ma MR, là c’est infiniment plus simple et léger que Hasura. Il n’y a plus tous les yaml metadata, juste un fichier de config json de quelques lignes.
> [@ManUtopiK](#):
>
> Le hot-realaod sur exo est juste magique.
Graphile propose aussi du hot reload, mais je n’ai pas testé.
> [@ManUtopiK](#):
>
> Aussi, la version open source n’a pas de rate limiter non plus. Il faut passer à la version payante 25€/mois…
Oui alors ça je l’ai bien vue, mais je pense qu’on peut faire nous même notre propre plugin pour ça sans trop de difficulté, grace à leur système de plugin, contrairement à Hasura.
Ils le disent eux même [très clairement](https://www.graphile.org/postgraphile/pricing/):
> These features integrate deeply with PostGraphile and have been optimized for its nuances by the maintainer. **If you wish to build and maintain protections yourself rather than using the Pro plugin, refer to [Production Considerations](https://www.graphile.org/postgraphile/production/) for information on how you might go about doing this**. Purchasing the Pro plugin helps fund ongoing development and maintenance on the open source PostGraphile project.
Il fournissent donc une page dédié à ça: [https://www.graphile.org/postgraphile/production/](https://www.graphile.org/postgraphile/production/)
Mais ça nécessite de passer par un middleware supplémentaire, chose que j’apprécie pouvoir éviter dans l’état actuel sur la stack squid/graphile que j’ai mis en place.
---
### Author:  [@ManUtopiK](https://forum.duniter.org/u/ManUtopiK)
#### Post date: [14 August 2025 16:43 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/10 "2025-08-14T16:43:50Z")
C’est du node.js donc il faut faire le rate limit nous même. Mais ça on peut faire la même chose avec Hasura avec un serveur node en amont…
Exemple d’implementation d’un rate limit et graphql query cost avec Fastify : [https://app.studyraid.com/en/read/12492/403981/rate-limiting-implementation](https://app.studyraid.com/en/read/12492/403981/rate-limiting-implementation)
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [14 August 2025 16:47 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/11 "2025-08-14T16:47:00Z")
Alors, pour le depth-limiter, Graphile propose déjà un plugin totalement open source fait pour ça (non spécifique à Graphile d’ailleurs):
> **[GitHub - graphile/depth-limit: A GraphQL.js validation rule for limiting the...](https://github.com/graphile/depth-limit)**
>
> A GraphQL.js validation rule for limiting the depth (including list depth) of GraphQL operations
Pour le rate limiter, il faut effectivement un petit middleware en node.js, de quelques lignes.
Au vue du peu de check que ça nécessite, je pense que l’impact sur les perf est négligeable.
Donc je pense que c’est ok de ce côté là.
* * *
edit: pour le rate limiter, bien vérifier que l’API reste exploitable pour la pagination sans trop de contrainte. Ne pas retomber dans le [piège de GVA](https://forum.duniter.org/t/nouveaux-membres-napparaissent-pas-sur-la-carte/13239/2).
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [17 August 2025 08:21 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/12 "2025-08-17T08:21:59Z")
Hier soir, j’ai mis en place les **subscriptions** avec Graphile. Contrairement à Hasura (_out of the box_), il a fallu configurer **LDS** , **wal2json** (PostgreSQL) et quelques réglages côté Graphile.
Elles reposent sur les changements **WAL** de Postgres : réactif et natif, mais il faudra vérifier la capacité à **scaler** avec des milliers d’apps et dizaines de subscriptions simultanées (script de monitoring prêt).
Ensuite j’ai donc pu faire:
- Ajout du plugin **depth limiter**
- Ajout du middleware **rate limiter**
- Filtrage des champs inutiles
Les limiters ont leurs tests unitaires associés et config en `.env` si besoin d’ajustement.
Aussi:
Tests de la **v5 beta** censé être mature : [pas concluant](https://github.com/graphile/crystal/issues/2671), beaucoup de changements.
Tests de **GraphJin** : subscriptions OK _out of the box_, mais architecture peu convaincante.
À un moment, j’ai reconsidéré l’idée de repasser au moteur GraphQL par défaut de SubSquid. Mais en relisant leur doc, on tombe désormais sur cette recommandation : [Serving GraphQL](https://docs.sqd.ai/sdk/resources/serving-graphql/) → le moteur intégré n’est plus prévu pour la prod, ils préconisent d’utiliser une solution externe: soit PostGraphile, soit Hasura → Lol (je vous jure que je n’avais pas vue ça avant de partir sur ces choix…)
Et donc évidemment, ce n’est que maintenant que je tombe sur ça: [GitHub - subsquid-labs/squid-postgraphile-example: A squid that uses PostGraphile to serve its GraphQL API](https://github.com/subsquid-labs/squid-postgraphile-example/)
Enfin, contact pris avec **Benjie** pour obtenir des garanties sur la pérennité open source du core de Graphile.
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [18 August 2025 16:50 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/13 "2025-08-18T16:50:39Z")
[Benjie](https://benjie.dev/) m’a très gentiment répondu, et m’a demandé de ne pas publier sa réponse mais en un mot, pas de garantie absolue, mais PostGraphile restera open source tant que la communauté le soutient financièrement et en visibilité (MP pour plus d’info).
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [19 August 2025 15:48 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/14 "2025-08-19T15:48:46Z")
7 posts were merged into an existing topic: [Add balances to squid accounts](https://forum.duniter.org/t/add-balances-to-squid-accounts/12782/16)
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [6 October 2025 12:43 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/15 "2025-10-06T12:43:37Z")
Le temps passe, si aucune objection, je mergerais ma branche Graphile sur master ce soir, et je pense par la même occasion totalement supprimer Hasura car en fait ça fou un peu la merde dans la metadata Hasura de garder 2 types de fonctions SQL, je pourrais passer du temps à adapter pour garantir la retro, mais honnêtement trop la flemme là, juste les nouveaux indexer seront sur Graphile et point barre, ça vous va ?
endpoint GQL /v1/graphql
Je vais par contre juste rajouter une query graphql pour connaitre le numéro de version de l’indexer ainsi que sont type (graphile).
---
### Author:  [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [6 October 2025 12:47 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/16 "2025-10-06T12:47:29Z")
Du coup, est-ce que cela reste compatible avec les clients ou est-ce que cela nécessite une adaptation ?
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [6 October 2025 12:50 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/17 "2025-10-06T12:50:48Z")
Vue que je compte supprimer Hasura, ça ne sera plus compatible avec les clients il faudra adapter.
Il faudra faire une requête de version pour savoir si compatible ou non.
Les changements sont mineurs, juste syntaxiques, mais il faudra les faires pour sûr.
---
### Author:  [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [6 October 2025 13:05 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/18 "2025-10-06T13:05:30Z")
Du coup, tu comptes rajouter la query graphql avant de supprimer Hasura ?
Ou bien on devrait considérer que l’absence de cette query signifie que ce n’est pas le nouveau type d’indexeur ?
Je ne sais pas si j’arriverai à regarder pour l’adaptation dans GCli, mais est-ce que tu as un peu de détail (ou une documentation en ligne ou …) sur les changements entre Hasura & Graphile qu’il faudra appliquer ?
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [6 October 2025 13:51 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/19 "2025-10-06T13:51:55Z")
> [@Nicolas80](#):
>
> Du coup, tu comptes rajouter la query graphql avant de supprimer Hasura ?
Oui voilà je viens de l’ajouter:
```auto
query {
version {
type
version
}
}
```
→
```auto
{
"data": {
"version": {
"type": "graphile",
"version": "0.4.0"
}
}
}
```
Il faudra faire une requête de version pour savoir si compatible ou non.
> [@Nicolas80](#):
>
> considérer que l’absence de cette query signifie que ce n’est pas le nouveau type d’indexeur ?
Effectivement avant la version 0.4.0 il faudra considéré l’absence de cette requête comme étant un noeud Hasura.
> [@Nicolas80](#):
>
> Je ne sais pas si j’arriverai à regarder pour l’adaptation dans GCli, mais est-ce que tu as un peu de détail (ou une documentation en ligne ou …) sur les changements entre Hasura & Graphile qu’il faudra appliquer ?
Les changements sont mineurs, juste syntaxique, mais il faudra les faire pour sûr.
En gros il y a les outils de comparaison qui changent de format, et comme je l’ai dit c’est un peu un merge entre les API relay et standard de Hasura, dont il faut reprendre les requêtes API relay et retirer `connection` du nom de la query et ajouter un `s`.
Mais vous pouvez facilement comparer un ancien endpoint avec cet nouveau endpoint graphile via ce GraphiQL: [https://gt-squid-graphile.axiom-team.fr/graphiql](https://gt-squid-graphile.axiom-team.fr/graphiql)
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [6 October 2025 19:46 UTC](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257/20 "2025-10-06T19:46:39Z")
> [@poka](#):
>
> Le temps passe
Malheureusement trop vite en effet.
À mon avis il vaut mieux supprimer Hasura sur la branche PostGraphile, mais pas merger sur master tant que les applis ne se sont pas toute adaptées. Ou alors merger, mais garder une branche historique Hasura pour savoir sur quoi publier les images du reboot gtest en attendant (par exemple pour faire marcher duniter panel). Je vais essayer de trouver un peu de temps pour relire ça, ce mois ci est plus cool que le mois de septembre qui était une dinguerie 😅
[Next page](https://forum.duniter.org/t/squid-postgraphile-as-graphql-engine-instead-of-hasura/13257.md?page=2)