Test suite for the type complexity analysis algorithm

[evanmcneely]

Summary

Changes are not 100% ready but I am requesting feedback and input on 1 particular problem I am having.

When working with lists in graphQL, the type complexity of the query is dependent on the number of objects returned in the list. For example, on line 263 in typeComplexityAnalysis.test.ts:

query = `
     Query { 
          human(id: 1) { 
               name, 
               friends { 
                   name 
                } 
           }
    }`;

the field friends is a list that returns an unknown number of objects in the response. How would we account for this when writing the complexity algorithm? Does this need to be accounted for the buildTypeWeights function?

Similarly on line 271 in typeComplexityAnalysis.test.ts,

query = 'Query {reviews(episode: EMPIRE, first: 3) { stars, commentary } }';

the number of objects in the response is 3, but it could 4, or 5. It's variable based on the client requests. Should the typeComplextyAnalysis algorithm take in the query variables as an argument in order to estimate maximum size that the response could be?

Type of Change

• New feature (non-breaking change which adds functionality)

Issues

closes #8

Evidence

[shalarewicz]

Re: your second question about taking into account first and limit arguments. Yes, I think we should do account for these in our calculation in order to get an accurate complexity estimate. So if the query is asking for the first: 3 Users and each User has a weight of 1 then the overall complexity would be 3. I think that the names of these variables would need to be defined somehow if the config so that the algorithm knows what arguments to look for. Maybe something like a paginationArgName and limitArgName that default to first and limit respectively.

As for unbounded lists. I'm not sure and I don't see a way to precompute this without having access to the database. We could have this to default to some value, make it configurable or cache the complexity each time an unbounded collection is resolved. The first call would be 'free' but after that there would be a somewhat accurate estimate assuming the list is called frequently enough

I'll poke around some of the existing packages and see if they handle this case.

[shalarewicz]

Is the question on line 259 how to calculate this in the actual implementation or in the tests?

[evanmcneely]

This is was with regards to implementing the algorithm. It was meant describe my thinking at that point and to imply that this test was weakly written. I can't say with any confidence that we should expect a complexity of 7 from this query. I'll skip it and make that clear until we figure how to handle these scenarios

[shalarewicz]

Just noting that we discussed the implementation using DFS/backtracking to compute complexity of nested queries.

[shalarewicz]

Minor but missing a 'e' in getQueryTypeComplxity and you can just use .toThrow() which checks if any error is thrown.

I agree on this function throwing an error. A question for the middleware then is do we want to pass the error down the middleware chain or send back a 400 status indicating a malformed request

[evanmcneely]

I was thinking we pass it onto to GraphQL to handle, so that thir error handling can respond with their error messages. We can discuss.

[shalarewicz]

If we use the parse() method and can respond to the client in the same way that GraphQL does then we can send the error back to the client. Otherwise calling next() will just let GraphQL handle this.

• Let's create an issue to dive further into error handling