4 ms·

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. GraphQL scares

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. GraphQL scares people because it seems to to allow arbitrary complex queries from applications. But that complexity was always there. REST just hides it in an unbounded number of predictable HTTP requests.

dmitriid 7y ago
The key word is: predictable. If your requests are predictable, then you can handle even the unbounded number.
bernawil 7y ago
I don't get the "arbitrary complexity" issue. It's only a problem if you're auto generating everything in your schema, but otherwise you limit the fields of problematic types by hand and that's it. The same computatational challenges we've always had with mapping relational models to REST didn't go away, mainly: N+1 queries, recursive types and query parameters adding complexity.
git-pull 7y ago
> 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-not-form-cycles http://facebook.github.io/graphql/#sec-Fragment-spreads-must..., https://github.com/graphql/graphql-spec/issues/91 https://github.com/graphql/graphql-spec/issues/91

dmitriid 7y ago

The key word is: predictable. If your requests are predictable, then you can handle even the unbounded number.

bernawil 7y ago

I don't get the "arbitrary complexity" issue. It's only a problem if you're auto generating everything in your schema, but otherwise you limit the fields of problematic types by hand and that's it. The same computatational challenges we've always had with mapping relational models to REST didn't go away, mainly: N+1 queries, recursive types and query parameters adding complexity.

git-pull 7y ago

> 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-not-form-cycles http://facebook.github.io/graphql/#sec-Fragment-spreads-must..., https://github.com/graphql/graphql-spec/issues/91 https://github.com/graphql/graphql-spec/issues/91