[kpmah]

The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data.

SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database.

A practical way to use SQL would be to expose the subset of data that is visible to the user and allow that to be queried by SQL, just like it would be by GraphQL or REST.

[aragilar]

Astronomy has been doing that for just over a decade: https://www.ivoa.net/documents/TAP/20100327/

[christkv]

We are doing this under the covers in our app using https://github.com/kofrasa/mingo to let us write data queries on the SPA side.

It lets us build reports and other configurable data queries in a standard way for our case.

I can completely see how this makes sense using SQL although I think the complexity of the implementation might be a fair bit higher than mingo.

[dimeatree]

I made the mistake of reading the comments before the article, and was stuck with the thought process of "but it's insecure"

Then I remembered my experience of working with an SQL-like based API, that was a pleasant surprise and joy to work with.

I do not see why we can't use it from a client-side perspective, and safely re-cast it server-side.

[jgwil2]

Okay, but what about the performance question? I assume this would apply to any language wrapping SQL. How does GraphQL prevent people from sending pathological queries that would wreck DB performance?