Concevoir des requêtes
Une fois que vous avez envoyé vos premières demandes de signature, vous voudrez utiliser davantage l'API. Le GraphiQL Explorer est un excellent endroit pour expérimenter, mais GraphQL peut encourager une attitude « je veux tout ». Quelques instants de réflexion vous épargneront des problèmes courants :
- Les données risquent-elles de devenir obsolètes ?
- Est-ce que je pénalise les performances de mon application avec un temps de démarrage inutilement long ?
Si vous utilisez quelque chose comme TanStack Query, vous comprendrez l'avantage de diviser les requêtes en morceaux pouvant être mis en cache et mis à jour de manière optimiste ou invalidés. Voici les lignes directrices que nous avons établies à travers une expérience douloureuse.
Évitez la profondeur excessive dans les listes
Évitez les requêtes sur des listes avec une profondeur d'arbre supérieure à 2. Pour les requêtes sur un seul élément, une profondeur plus grande est acceptable.
Parfois, il vaut la peine d’utiliser des champs agrégés sur le parent pour éviter de déclencher des résolveurs supplémentaires. Par exemple, si l’important à propos d’un Batch est le nombre de documents qu’il contient (qui peuvent être des milliers), utilisez le champ documentCount plutôt que de récupérer la documentConnection complète.
Isolez les types de données
Gardez les types d’objets dans des requêtes séparées, sauf si les données changent lentement et sont globales (comme les paramètres de rétention de Group). Cela ne semble pas important jusqu’au moment où vous devez invalider un cache ou mettre à jour un enregistrement de manière optimiste — alors vous serez content que chaque type ait sa propre clé de requête.
Testez les modifications des requêtes
Un changement rapide dans une requête peut entraîner une pénalité de performance inattendue. Nous avons trouvé plusieurs cas de requêtes auparavant rapides qui sont devenues lentes au fil des générations de modifications. Fixez une limite de temps conceptuelle pour les requêtes selon votre intégration, et vérifiez les performances lorsque vous les modifiez.
Voir aussi
- Qu’est-ce que l’overfetching ? — pourquoi demander moins de données est important
- Comment fonctionne la pagination — récupérer de grands ensembles de résultats efficacement