Investigate GraphQL dedupe optimizations

[stephenh]

The difference between, top-level queries:

query {
  bookReviews {
    book { author { name } }
  }
}

And subgraph queries:

query {
  authors {
    name
    books { bookReviews { ... } }
  }
}

Can be surprisingly large due to the duplication of author { name } that is from the top-level query.

In particular we've seen, for returning the same data set:

• 60% bigger payload (690kb vs. 1.1mb), and
• 70% more JSON fields (22k vs 37k)

Which translates to more CPU time spent:

1. Re-invoking duplicate resolvers (the same author.name every time)
2. Re-invoking duplicate auth checks (the same author.name auth check multiple times)
3. JSON.stringify-ing the payload
4. gziping the payload

Solutions like graphql-crunch help dedupe the data but only happen after we've already called the resolvers, and so have to spend its own CPU time running the dedup process.

Ideally we could lean into the GraphQL __typename + id convention for identities and only a) invoke resolvers once, and b) produce a payload that is essentially the GraphQL crunch output but directly as we go, instead of having to crunch after the fact.

[stephenh]

Closing as this isn't really related to Joist.