| > Restricting the queries is backwards. You expose should only expose the few that makes sense in the domain of your app, and optimise for those. With exceptions: Preventing endless recursion: Or else it'd be possible for a client to timeout with queries [1]. In graphene recursion can be checked via `info.path`. Calculated / slow fields: Makes more sense to have dedicated objects if calculations are involved, so if they're lists/connections, there can be limits imposed for how many can be grabbed at a time. Sometimes the only way to be sure is to only allow access to these objects if they're a direct ID lookup at the root, e.g: repos(id: <ID>) -> stats -> TotalLikesForAllIssues. Assume that if cold and uncached, it could take <1s to calculate that. Imagine if we were to have that ran multiple times: User -> repos(first: 20) -> stats -> TotalLikesForAllIssues. So in my case I want to make the data available, but it's not always a direct mapping to SQL. And I'm also making rules inside where the client is limited in how, and how much they can query. [1] Further reading: http://facebook.github.io/graphql/#sec-Fragment-spreads-must..., https://github.com/graphql/graphql-spec/issues/91 |