Re:A principled approach to GraphQL query cost analysis
by tunesmith on Monday June 29, 2020 @01:55PM
(#23680187)
The most recent discussions have had to do with how to handle queries that return different results depending on whether the user making the query is authenticated; whether to use the same resolver or to instead require the frontend to use a different "whateverPublic" query if they know the user isn't authenticated.
Another is what to do when subqueries yield errors. We're often faced with three choices there: whether to make the entire query return an error, or make the subquery return a friendly error, or make the subquery return null/empty.
Finally, we're suspecting that in most cases where it might first appear we need a dataloader, maybe we don't if we change how the frontend queries, since the "+1" part of the "N+1" can often make its own group query to whatever repository we're using.
Re:A principled approach to GraphQL query cost analysis
by zaksingh on Monday June 29, 2020 @06:02PM
(#23683788)
If you aren't already, I strongly recommend using union types for query results with inline fragments in your queries themselves. This handles both your auth/unauth case as well as error handling. This pattern isn't discussed much in tutorials/docs, but has been absolutely essential for us.
Care to share any specific problem you are currently facing?