Concernant l’indexation des données, on a besoin d’une solution demandant le moins de dev spécifiques possibles tout en accordant les meilleures performances possibles. Pour ça il faut privilégier une solution faite pour substrate si ça existe.
Dans le cadre de mon boulot UNL j’ai assisté cette semaine à une présentation de Hydra par un de leurs développeurs. je croyais (a tort), que ça générai juste une API graphql en proxy de l’API rpc, mais en fait c’est bien plus que ça: Hydra inclus tout ce qu’il faut pour historiser et indexer toutes les données émises par la blockchain, et fourni en plus un moteur de recherche full-text. En gros l’équivalent de ce que font les nœuds Cs+ concernant l’indexation des données issues de la blockchain ! Et comme c’est fait pour substrate ça nous demandera moins de travail que d’autres solutions. Concernant les perf c’est du postgres caché par du redis, et leur architecture deux tiers permet de suivre la blockchain quoi qu’il arrive.
GitHub - Joystream/hydra: A Substrate query node framework
J’ai pu poser quelques questions au développeur en question, et j’ai récupéré son mail et son telegram. Hydra nous permettrais de gérer toute la partie indexation et historisation des données, avec recherche full-text incluse. Et comme c’est fait pour substrate ça nous demandera moins de travail que d’autres solutions. Concernant les perf c’est du postgres caché par du redis, donc ça dépote.
Deux inconvénients toutefois:
- L’api générée (graphql) permet que de lire des données, pas d’écrire. Donc si on utilise que ça les clients devraient taper quand même l’api rpc pour soumettre des extrinsics, mais on peut faire une fédération graphql pour gérer la partie mutation sur une autre brique technique, bref c’est pas bloquant.
- Pour le moment ça n’indexe que les blocs finalisés, donc on aurait pas les dernières minutes, mais ils ont pour projet de gérer le revert donc c’est juste une question de temps.
Bon ça ne répond qu’aux besoins liés aux données générées par la blockchain (besoin essentiel), pour ce qui est de gérer les données qui ne sont pas générées par la blockchain je suis encore en pleine réfléxion.
Une piste que je creuse est d’avoir les hashs des données en blockchain et les données elles-mêmes dans une DHT. Je ne sais par encore si le mieux est que chaque nœud de la DHT soit un nœud substrate lui-même (car substrate inclus déjà la dépendante pour ça), ou si un binaire à part serait mieux pour ça, afin de partir sur une architecture micro-services (avec un docker compose pour déployer tout ça comme si c’était un seul nœud).
Reste à savoir comment indexer, car si on a pas le hash il faut pouvoir chercher d’une façon ou d’une autre.
Pour les noms de profil en particulier j’ai pas envie qu’on reproduise la même erreur de les stocker en double sur deux couches différentes (Duniter / Cs+).
Une possibilité est de les passer dans les extrinsics pour qu’ils puissent être indexés par Hydra.
Ce qui est passé en paramètre d’un extrinsics ne se retrouve pas forcément dan le storage on-chain, c’est la logique codée dans le runtime qui le décide. En fait un nœud substrate stocke deux choses différentes:
- L’état on-chain (nommé on-chain storage dans la doc de substrate)
- Les blocs.
Ce qu’on passe en paramètre d’un extrinsic se retrouve dans de bloc, mais pas forcément dans l’état on-chain, or seul l’état on-chain doit être obligatoirement conservé par tous les nœuds substrates, les anciens blocs peuvent être oubliés (paramétrable par nœud).