Squid: PostGraphile as GraphQL engine instead of Hasura

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.
  • 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 !
    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.
Si certains d’entre vous connaissent, je suis preneur de vos retours.

J’explique un peu tout ça dans le README de la branche.

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

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

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 :teacup_without_handle: ).

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.

8 Likes

TL;DR

Hasura casse les couilles, remplacé par Graphile, mode hybride, pas casser, migration progressive, votre avis.

1 Like

Je ne connais pas graphile mais, pour info, on a remplacé hasura par exograph pour l’api d’axiom team.

1 Like

Ah ok, tu peux dire un mot du pourquoi ? Mêmes raisons que moi ? Les avantages que vous voyez à exograph (je ne connais pas) ?

faudrait demander à @ManUtopiK !
A part “c’est du rust” et “pour le fun” je sais pas vraiment pourquoi on s’est lancé la dedans :stuck_out_tongue:
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 !

1 Like

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 en licence Apache2 a terme. Absence de change date, donc au bout de 4 ans maximum, 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.
4 Likes

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…

4 Likes

Le hot-realaod sur exo est juste magique. Tu as testé leur Playground | Exograph ?
Tu as exo, postgres en wasm et graphiql sur la même page !

1 Like

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.

Graphile propose aussi du hot reload, mais je n’ai pas testé.

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:

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 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/

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.

1 Like

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

1 Like

Alors, pour le depth-limiter, Graphile propose déjà un plugin totalement open source fait pour ça (non spécifique à Graphile d’ailleurs):

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.

3 Likes

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, 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 → 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

Enfin, contact pris avec Benjie pour obtenir des garanties sur la pérennité open source du core de Graphile.

5 Likes

Benjie 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).

3 Likes

7 posts were merged into an existing topic: Add balances to squid accounts