Vai al contenuto principale

Progettare Query

Una volta che hai inviato le prime richieste di firma, vorrai utilizzare più l'API. Il GraphiQL Explorer è un ottimo posto per sperimentare, ma GraphQL può incoraggiare un atteggiamento del tipo "voglio tutto". Qualche momento di riflessione ti salverà da problemi comuni:

  • I dati potrebbero diventare obsoleti?
  • Sto compromettendo le prestazioni della mia applicazione con un tempo di avvio inutilmente lungo?

Se stai usando qualcosa come TanStack Query, capirai il vantaggio di suddividere le query in blocchi memorizzabili nella cache che possono essere aggiornati ottimisticamente o invalidati. Ecco le linee guida che abbiamo elaborato attraverso un'esperienza dolorosa.

Evita annidamenti profondi nelle liste​

Evita query di liste con una profondità ad albero maggiore di 2. Nelle query per singoli elementi, un annidamento più profondo va bene.

A volte vale la pena usare campi aggregati nel genitore per evitare di attivare risolutori extra. Per esempio, se la cosa importante riguardo a un Batch è quanti documenti contiene (che possono essere migliaia), usa il campo documentCount invece di recuperare l'intera documentConnection.

Isola i tipi di dati​

Mantieni i tipi di oggetto in query separate a meno che i dati non siano a lenta variazione e globali (come le impostazioni di conservazione Group). Questo non sembra importante finché non ti serve invalidare una cache o aggiornare ottimisticamente un record — allora sarai contento che ogni tipo abbia la propria chiave di query.

Testa le modifiche alle query​

Una rapida modifica a una query può comportare una penalità di prestazioni inaspettata. Abbiamo trovato diversi casi di query precedentemente veloci che si sono trasformate in lente attraverso generazioni di modifiche. Imposta un limite di tempo concettuale per le query a seconda della tua integrazione, e controlla le prestazioni quando le modifichi.

Vedi anche​

Export This Article

Save a copy of this page as PDF or plain text.