Docs
⌘ K

3 minutes

Bonne pratique pour les subgraphs 2 - Améliorer la Réactivité de l'Indexation et des Requêtes en Utilisant @derivedFrom

TLDR

Les tableaux dans votre schéma peuvent vraiment ralentir les performances d’un Subgraph lorsqu’ils dépassent des milliers d’entrées. Si possible, la directive @derivedFrom devrait être utilisée lors de l’utilisation de tableaux, car elle empêche la formation de grands tableaux, simplifie les gestionnaires et réduit la taille des entités individuelles, ce qui améliore considérablement la vitesse d’indexation et les performances des requêtes.

Comment Utiliser la Directive @derivedFrom

Il vous suffit d’ajouter une directive @derivedFrom après votre tableau dans votre schéma. Comme ceci :

comments: [Comment!]! @derivedFrom(field: "post")

@derivedFrom crée des relations efficaces d’un à plusieurs, permettant à une entité de s’associer dynamiquement à plusieurs entités apparentées sur la base d’un champ de l’entité apparentée. Cette approche évite aux deux parties de la relation de stocker des données en double, ce qui rend le Subgraph plus efficace.

Exemple de cas d’utilisation de @derivedFrom

Un exemple de tableau à croissance dynamique est une plateforme de blogs où un “Post” peut avoir de nombreux “Comments”(Commentaires).

Commençons avec nos deux entités, Post et Comment

Sans optimisation, vous pourriez implémenter cela avec un tableau :

type Post @entity {  id: Bytes!  title: String!  content: String!  comments: [Comment!]!}type Comment @entity {  id: Bytes!  content: String!}

Les tableaux comme ceux-ci stockeront effectivement des données supplémentaires de Comments du côté Post de la relation.

Voici à quoi ressemble une version optimisée utilisant @derivedFrom:

type Post @entity {  id: Bytes!  title: String!  content: String!  comments: [Comment!]! @derivedFrom(field: "post")}type Comment @entity {  id: Bytes!  content: String!  post: Post!}

En ajoutant simplement la directive @derivedFrom, ce schéma ne stockera les “Comments” que du côté “Comments” de la relation et non du côté “Post” de la relation. Les tableaux sont stockés sur des lignes individuelles, ce qui leur permet de s’étendre de manière significative. Cela peut entraîner des tailles particulièrement grandes si leur croissance est illimitée.

Cela ne rendra pas seulement notre Subgraph plus efficace, mais débloquera également trois fonctionnalités :

  1. Nous pouvons interroger le Post et voir tous ses commentaires.

  2. Nous pouvons faire une recherche inverse et interroger n’importe quel Commentaire et voir de quel post il provient.

  3. Nous pouvons utiliser [Chargeurs de champs dérivés] (/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) pour débloquer la possibilité d’accéder directement aux données des relations virtuelles et de les manipuler dans nos mappages de Subgraph.

Conclusion

Utilisez la directive @derivedFrom dans les Subgraphs pour gérer efficacement les tableaux à croissance dynamique, en améliorant l’efficacité de l’indexation et la récupération des données.

Pour une explication plus détaillée des stratégies permettant d’éviter les tableaux volumineux, consultez le blog de Kevin Jones : Bonnes pratiques en matière de développement de subgraphs : éviter les tableaux volumineux.

Bonnes pratiques pour les subgraphs 1-6

  1. Améliorer la vitesse des requêtes avec l’élagage des Subgraphs

  2. Améliorer l’indexation et la réactivité des requêtes en utilisant @derivedFrom

  3. Améliorer l’indexation et les performances des requêtes en utilisant des entités immuables et des Bytes comme IDs

  4. Améliorer la vitesse d’indexation en évitant les eth_calls

  5. Simplifier et optimiser avec les séries chronologiques et les agrégations

  6. Utiliser le greffage pour un déploiement rapide des correctifs