Hacker News Reader

Comment by throwaway66666 | Hacker News Reader

I understand and agree with you with the issues about REST. But I still don't understand why GraphQL is not unsafe. For example, assuming that we have an endpoint that returns a list of users but skips banned users. Would I have to do something like query{user(banned:0)} ? That would be pretty unsafe as well. So how is graphql different than executing limited queries on the server?

View on HN

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.

GraphQL queries are strongly typed. You can only add fields for what your schema defines. And no, in that case you would simply have a users query and in the GraphQL resolver on the server side for that query you would just filter out banned users. If there's anything you don't want exposed to the client, you simply leave it out of your graphql schema.

Got it. So the above example that I gave with SQL is pretty much the same thing as GraphQL. Assuming you would have a SQL resolver that just like the GraphQL resolver filters out things that should never hit the DB. So GraphQL is a middleware for safely querying the database openly by untrusted 3rd parties. Thanks that explains a lot, it's a pretty interesting idea actually

Not just a database; any data source.

The piece that got me hooked on GraphQL (prior to implementing servers with it, and now I really like GraphQL—but it’s not a silver bullet in any way) was a podcast where one of the creators of GraphQL at FB made it clear that, from the server side, every field in GraphQL is a function, not a field on a record.

It means that, although the FE is specifying the shape of the data it wants, the BE can determine whether to return the data or not. Also, errors are additive and may be returned in parallel to the requested data fields.

Reply on news.ycombinator.com