DEV Community

Discussion on: How is GraphQL different from the old days?

 
artis3n profile image
Ari Kalfus

The difference is the graphql schema creates valid sql in a prepared statement, it just might not be what you would normally allow the user to retrieve.

But yes, validation of user input is key. GraphQL needs some better tooling support around that.

Thread Thread
 
defman profile image
Sergey Kislyakov • Edited

It depends on the implementation. I've once used GraphQL in a pet project and you could only pass some generic values (e.g. ids) and then select fields you want, for example:


query {
    user(id: 1) {
        login
        name
        posts {
            id
            title
        }
    }
}

id there would be passed to an ORM (Users.get(by: id).with(model: Post)) and I'd simply return this data to my GraphQL level which then would fetch everything user requested (so if my User model has id, email, etc., a GraphQL library would only take login and name from it and posts would return an array of posts that would be handled the same way) and return it to them. I've fetched everything I needed in one query compared to 2 REST calls (/api/users/1, /api/users/1/posts) and it's pretty safe as long as you prepare the id value under the hood. I doubt anyone uses GraphQL just like a SQL generator. It's not safer than exposing a raw SQL endpoint like /api/sql/$whatever_sql_you_can_come_up_with?variable=;drop everything; --lul.

Of course there are downsides such as complexity and attribute accessibility by roles, though I've implemented that by dynamic attributes that would return an error/null if you don't have permission to read this attribute. And the complexity problem was solved by the library itself - I simply put a limit on the depth of the query, so you can't do something like query { users { posts { user { posts { user ... } } } }