4 ms·
Unlimited query complexity: - graphql() function takes "validators" argument for a reason ;) There are multiple strategies for limiting complexity, but common
by Ralfp 7y ago
Unlimited query complexity:
- graphql() function takes "validators" argument for a reason ;) There are multiple strategies for limiting complexity, but common ones are boxing (limiting depth and width of query) or query cost limitation.
For auth, you authenticate user using custom middleware before entering the query executor. Inside query executor you can do one of many things, depending on what makes sense for you: error field resolution, return "null", or return custom type like "ObjectNotFoundError".
For caching, you cache inside resolvers that do something costful, or in data loaders those resolvers call.
- davnicwil 7y agoThanks for this reply! Are things like query depth, width and cost limiting available as parameters to common libraries? On the auth thing, one thing I commonly do with REST is have a general 'is this user authenticated' middleware and then later have a 'permissions' middleware that checks if the user has rights to see/modify the thing they are trying to, but that's at the service level for that particular thing. Would you follow a similar strategy in GraphQL? Generic auth in a middleware for a user, then specific access management auth inside specific resolvers later on?
- Ralfp 7y ago> Are things like query depth, width and cost limiting available as parameters to common libraries? No, they are mostly 3rd party utils. I those exist for Apollo server. > Would you follow a similar strategy in GraphQL? Generic auth in a middleware for a user, then specific access management auth inside specific resolvers later on? Yes. Or I would move auth check up a level, and implement schema directive like "@authenticated" or "@hasPerm("perm")" so resolver would do only data resolution, but each approach has advantages and downsides.