You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I really like graphql-crunch; great work! Out of curiosity, have you considered extending the "crunching" to go all the way into the resolver runtime itself?
I.e. if I've already called authorResolver.name(a1), just don't call that name for a1 again during the rest of this request.
Granted, this would need to rely on __typename+id semantics for identity, and also an understanding from resolvers that they won't change their output based on "where in the graph the object was fetched", i.e. anything in the 4th/info param of the resolver.
But, assuming that was the case, it seems like this could slice off a whole slew of work that apollo/graphql tools puts into making a giant JSON-with-repeated-info tree that graphql-crunch is going to immediately throw away ~70% of.
Thanks!
The text was updated successfully, but these errors were encountered:
I really like graphql-crunch; great work! Out of curiosity, have you considered extending the "crunching" to go all the way into the resolver runtime itself?
I.e. if I've already called
authorResolver.name(a1)
, just don't call thatname
fora1
again during the rest of this request.Granted, this would need to rely on
__typename+id
semantics for identity, and also an understanding from resolvers that they won't change their output based on "where in the graph the object was fetched", i.e. anything in the 4th/info param of the resolver.But, assuming that was the case, it seems like this could slice off a whole slew of work that apollo/graphql tools puts into making a giant JSON-with-repeated-info tree that graphql-crunch is going to immediately throw away ~70% of.
Thanks!
The text was updated successfully, but these errors were encountered: