Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The equivalent REST implementation would be `/users?banned=0`, which would be equally unsafe if you didn't want clients to view banned users.

In both instances, you would want to implement client authorization, so only clients with special permissions would be able to execute that query, or would simply get a different super/subset of users.

I think you're conflating the purposes of GraphQL with that of SQL. GraphQL is not meant to be a general-purpose, all-powerful, turing-complete query language like SQL, it is simply a way for clients to specify the exact data structure they require, based on a server-defined schema.

Authorization issues like you highlighted would have similar solutions under both implementations, GraphQL does not claim to do that out of the box.



Plain old SQL92 is not turing complete. It's just a DSL for working with structured data. Via https://stackoverflow.com/questions/900055/is-sql-or-even-ts...

SQL could work here but I think GraphQL is better for client apps anyway because it's based on very easily serialized graph structures instead of a string of english words that must be parsed. The client and the server can both work with it much more easily.

I think if you wanted to, you could map SQL onto GraphQL. Someone might have already done that. The opposite is also very likely already done (GraphQL mapped to SQL).


somehow I knew someone would call me out on that. HN does not disappoint.


Unfairly, in my opinion. SQL92 is not Turing complete, yes. SQL92 is pretty old, and implementations have definitely added features since then. The more-upvoted response immediately above the one provided in that StackOverflow question provides examples of Turing completeness in SQL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: