ajs139
commented
7 years ago Similarly, if you are able to generate the full response higher-up the graph, it is not currently possible to prevent resolve being called on all the child objects. Let's say we have a Schema such as this:
type Star {
id: Int
name: String
}
type Galaxy {
name: String
stars: [Star]
}
type Query {
milkyWay: Galaxy
}
schema {
query: Query
}And the following query:
query {
milkyWay {
stars {
name
}
}
}Let's assume the stars field has the ability to make a single request such as select star.name from stars inner join galaxy on star.id = galaxy.star_id where galaxy.name = 'Milky Way' and the result is already in the format of being an array of {name} objects. In this case, we do not want to iterate over every star - it's already populated in the correct format.
Having the ability for a resolver to do a 'full resolution' could be a huge performance gain in certain situations such as this, since the time to recursively iterate over a large data-set can be significant.
leebyron
ericclemmons
cagdastulek
terencechow
Originally posted here:
I'm trying to resolve some performance issues with large documents, and the problem (AFAICT) is due to the pruning of the document based on requested fields.
Here's how I discovered it:
2s - 4s response time.
Even if I use
formatResponse(response) { return [] }to pretend nothing came back , it's still a problem somewhere beforeformatResponse.106ms response time.
In the resolver, If I do:
And then use
formatResponseto do:I can see the response starting & streaming much faster.
A co-worker tried
masterto see if #710 resolves it, but it does not appear so.For reference on why we have a document this large, it's because, internally, we leverage GraphQL to fetch a full document that we then reduce into a separate document that describes the state of key entities for internal tooling.
(For example, "why does this product not appear for users in Texas?")
Because of the complex (programmatic) rules that run against these documents, we're showing internal users the unfiltered document and filtering using the same logic that happens in user-land.
In the short-term, it appears our best option is to find a means of returning an unfiltered document (for performance) for internal uses?