L’architecture The Graph Client

Pour répondre à la nécessité de prendre en charge un réseau distribué, nous prévoyons de prendre plusieurs mesures pour faire en sorte que The Graph client fournisse tout ce dont l’application a besoin :

1. Composer plusieurs subgraphs (côté client)
2. Repli sur plusieurs Indexeurs/sources/services hébergés
3. Stratégie de prélèvement automatique/manuel à la source
4. Un noyau agnostique, avec la possibilité d’exécuter des intégrations avec n’importe quel client GraphQL

Mode Standalone

Avec n’importe quel client GraphQL

Composition d’un subgraph

Pour permettre une composition simple et efficace côté client, nous allons utiliser graphql-tools⁠ pour créer un schéma / Executor distant, qui peut ensuite être accroché au client GraphQL.

L’API peut être soit des transformateurs graphql-tools bruts, soit l’utilisation de l’API déclarative GraphQL-Mesh⁠ pour composer le schéma.

Stratégies d’exécution des subgraphs

Dans chaque subgraph défini comme source, il sera possible de définir l’Indexeur de la (des) source(s) et la stratégie d’interrogation, dont voici quelques exemples :

Pour pousser le concept de stratégies à l’extrême, nous pouvons même construire une couche magique qui fait de l’abonnement en tant que requête, avec n’importe quel crochet, et fournit un DX fluide pour les dapps :

Avec ce mécanisme, les développeurs peuvent écrire et exécuter des subscriptions GraphQL, mais sous le capot, nous exécuterons une requête GraphQL vers les Indexeurs de The Graph, et nous permettrons de connecter n’importe quel hook/probe externe pour ré-exécuter l’opération. De cette façon, nous pouvons surveiller les changements sur le Smart Contract lui-même, et le client GraphQL comblera l’écart sur le besoin de changements en temps réel de The Graph.