este problema se puede resolver de diversas maneras, por lo tanto te damos la que en nuestra opinión es la solución más completa.
Solución:
Tendrás que analizar el info
objeto que se pasa al resolver como su cuarto parámetro. Este es el tipo para el objeto:
type GraphQLResolveInfo =
fieldName: string,
fieldNodes: Array,
returnType: GraphQLOutputType,
parentType: GraphQLCompositeType,
schema: GraphQLSchema,
fragments: [fragmentName: string]: FragmentDefinition ,
rootValue: any,
operation: OperationDefinition,
variableValues: [variableName: string]: any ,
Puede atravesar el AST del campo usted mismo, pero probablemente sea mejor que use una biblioteca existente. Recomiendo graphql-parse-resolve-info. Hay una serie de otras bibliotecas por ahí, pero graphql-parse-resolve-info
es una solución bastante completa y en realidad se usa bajo el capó por postgraphile
. Ejemplo de uso:
posts: (parent, args, context, info) =>
const parsedResolveInfo = parseResolveInfo(info)
console.log(parsedResolveInfo)
Esto registrará un objeto a lo largo de estas líneas:
alias: 'posts',
name: 'posts',
args: ,
fieldsByTypeName:
Post:
author:
alias: 'author',
name: 'author',
args: ,
fieldsByTypeName: ...
comments:
alias: 'comments',
name: 'comments',
args: ,
fieldsByTypeName: ...
Puede recorrer el objeto resultante y construir su consulta SQL (o conjunto de solicitudes de API, o lo que sea) en consecuencia.
Aquí hay un par de puntos principales que puede usar para optimizar el rendimiento de sus consultas.
- En su ejemplo, sería de gran ayuda usar https://github.com/facebook/dataloader. Si carga comentarios en sus resolutores a través del cargador de datos, se asegurará de que estos se llamen solo una vez. Esto reducirá significativamente la cantidad de llamadas a la base de datos, ya que en su consulta se demuestra el problema N+1.
- No estoy seguro de qué información exacta necesita obtener en las publicaciones con anticipación, pero si conoce las identificaciones de las publicaciones, puede considerar “mirar hacia adelante” pasando las identificaciones ya conocidas a los comentarios. Esto asegurará que no necesite esperar las publicaciones y evitará las llamadas de árbol de graphql y podrá resolver los comentarios sin esperar las publicaciones. Este es un excelente artículo para optimizar las solicitudes de cascada de GraphQL y podría darnos una buena idea de cómo optimizar sus consultas con el cargador de datos y mirar hacia adelante https://blog.apollographql.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051
Te mostramos las reseñas y valoraciones de los lectores
Al final de todo puedes encontrar las críticas de otros gestores de proyectos, tú igualmente tienes la habilidad dejar el tuyo si lo crees conveniente.