Slow response times with large documents #723
Description
Originally posted here:
https://apollographql.slack.com/archives/general/p1487368874010273
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:
Query: {
async something(...) {
...do something that takes 100ms...
return oneMbOfJSON;
}2s - 4s response time.
Even if I use formatResponse(response) { return [] } to pretend nothing came back , it's still a problem somewhere before formatResponse.
Query: {
async something(...) {
...do something that takes 100ms...
return []; // Did the work, but not bother sending it back
}106ms response time.
In the resolver, If I do:
context.payload = oneMbOfJSON;
return [];And then use formatResponse to do:
{ data: options.context.payload }I can see the response starting & streaming much faster.
A co-worker tried master to 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?