…
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 querytransferWithUd
, 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 ).
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.