Comment by throwaway66666 | Hacker News Reader

Comment by throwaway66666 | Hacker News Reader

Parent Full thread

I have 2 very naive questions about graphql. I am not trying to poke holes or antagonize, I just want to learn.

1. First one is, if graphql is a query language - why not use an existing query language that many people are familiar with already? Eg instead of doing "query{ users(limit: 10) }" why not just send in the request's body "SELECT * FROM users LIMIT 10;" Or an ORM like query and have the server execute that (after of course parsing/sanitizing/normalizing it first)?

Why do we need one more ORM like language/abstraction on top of already our language abstractions? If my backend is in Postgres and ElasticSearch, can't I just have the client shoot sql and ES json queries instead? Why the new language?

2. How does it secure against the client trying to make super heavy queries? I always find it funny (and it is a good lesson) when an intern writes an ElasticSearch query that tries to return a 300gb JSON object back to the browser and crashes everything in the process (not production of course). I 've read that GraphQL has built-in checks for timeouts and query complexity, but if I am able to write optimized and highly performant SQL is there any guarantee that the GraphQL layer will output the same results?

To answer your first question, GraphQL allows the client to safely declare exactly what data it needs based on the GraphQL schema.

We don't want clients to be able to arbitrarily execute server side SQL queries, that's dangerous and unsafe. Which is why REST is even used as an abstraction over the backend in the first place.

The problem with REST is that it's not very adaptable. Any time a client needs a slightly different payload, either an entirely new endpoint has to be created on the server side or you have to version the API to handle evolving use cases.

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?

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.

It doesn't secure the client inherently against super-heavy queries. GraphQL is a spec, that's an implementation concern.

One cool thing though is that if you define an schema that includes a field that is expensive to resolve, the server will only attempt to resolve it if asked to by the client (defined by the query it sends), whereas a REST implementation would still need to resolve the field, even if the client in question isn't making use of it.

Reply on news.ycombinator.com