Saltar al contenido principal

Diseñando Consultas

Una vez que hayas enviado tus primeras solicitudes de firma, querrás usar más de la API. El GraphiQL Explorer es un excelente lugar para experimentar, pero GraphQL puede fomentar una actitud de "lo quiero todo". Unos momentos de reflexión te salvarán de problemas comunes:

  • ¿Es probable que los datos se vuelvan obsoletos?
  • ¿Estoy perjudicando el rendimiento de mi aplicación con un tiempo de inicio innecesariamente largo?

Si estás usando algo como TanStack Query, entenderás el beneficio de dividir las consultas en porciones cacheables que pueden actualizarse optimistamente o invalidarse. Aquí hay pautas que hemos elaborado a través de una experiencia dolorosa.

Evita el Anidamiento Profundo en Listas​

Evita consultas de listas con una profundidad de árbol mayor a 2. En consultas de un solo ítem, un anidamiento más profundo está bien.

A veces vale la pena usar campos agregados en el padre para evitar activar resolutores extra. Por ejemplo, si lo importante en un Batch es cuántos documentos contiene (que pueden ser miles), usa el campo documentCount en lugar de obtener la conexión completa de documentConnection.

Aísla los Tipos de Datos​

Mantén los tipos de objetos en consultas separadas a menos que los datos cambien lentamente y sean globales (como los ajustes de retención de Group). Esto no parece importante hasta que necesitas invalidar una caché o actualizar optimistamente un registro — entonces estarás agradecido de que cada tipo tenga su propia clave de consulta.

Prueba Cambios en las Consultas​

Una ligera modificación a una consulta puede traer una penalización de rendimiento inesperada. Hemos encontrado varios casos de consultas que antes eran rápidas y que se volvieron lentas tras generaciones de cambios. Establece un límite conceptual de tiempo para las consultas según tu integración, y verifica el rendimiento cuando las modifiques.

Ver También​

Export This Article

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