You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently I have been migrating all of my graphql queries from a custom postgraphile api to the supabase graphql api. During the migration I was investigating which safety measures I can implement against large (accidental) queries. I found that the max number of rows returned is 30 and totalCount is disabled by default. But I can't find whether I can configure the maximum query depth for a graphql query. This means 30 rows for each level of the query, but if that query can go 20 levels deep, the response will be huge.
I found the default timeout settings for users: 3 sec (anon), 8 sec (authenticated). But for an authenticated user they can probably use up quite some resources in 8 seconds if I don't limit the query depth.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Recently I have been migrating all of my graphql queries from a custom postgraphile api to the supabase graphql api. During the migration I was investigating which safety measures I can implement against large (accidental) queries. I found that the max number of rows returned is 30 and totalCount is disabled by default. But I can't find whether I can configure the maximum query depth for a graphql query. This means 30 rows for each level of the query, but if that query can go 20 levels deep, the response will be huge.
I found the default timeout settings for users: 3 sec (anon), 8 sec (authenticated). But for an authenticated user they can probably use up quite some resources in 8 seconds if I don't limit the query depth.
Does anyone know what a good approach is here?
Beta Was this translation helpful? Give feedback.
All reactions