4 ms·

What if you had one one endpoint called xyz.com/sqlquery and you would just send it a SQL Query in the form a string, the server would validate it and authorize

by typon 9y ago

What if you had one one endpoint called xyz.com/sqlquery and you would just send it a SQL Query in the form a string, the server would validate it and authorize it and return the data or reject the request. Is that different than GraphQL?

nijynot 9y ago
Then you need to validate, authorize, etc. queries correctly. I see no reason why anyone would want this. Instead use GraphQL which is a thin layer, and hide all the business logic behind it. Way more manageable.
TheCoelacanth 9y ago
The difference is that GraphQL was designed to be used like that, so it is relatively easy to limit what capabilities the client can use. SQL was not designed to be used like that, so for complex queries it will be very difficult to verify that the client isn't doing something that it isn't allowed to do.
scotty79 9y ago
The difference is that you'd have to have very smart query builder on the front end side that would construct one sql query from combined declared needs of all the front-end components on one page. Then after it gets response (flat as is usual with sql) it would have to split it up and feed to all of the components. On the backend you'd probably need sql query analyser that would figure out which tables and rows query touches to determine if currently logged in user should be able to see this data. So on frontend you need a language in which components can specify their needs (why not graphql?). Next step is asking youself why flatten those to sql before sending them to server only to have it parsed again by the server. It's easier to pass them as grqphql and let server decide if it should respond and draw from data source (or possibly multilple data sources, for example solr and database). Congrats, you invented graphql. Too bad nobody came up with that 15 years ago, this could save a lot of people a lot of trouble.

by typon 9y ago

nijynot 9y ago

Then you need to validate, authorize, etc. queries correctly. I see no reason why anyone would want this. Instead use GraphQL which is a thin layer, and hide all the business logic behind it. Way more manageable.

TheCoelacanth 9y ago

The difference is that GraphQL was designed to be used like that, so it is relatively easy to limit what capabilities the client can use. SQL was not designed to be used like that, so for complex queries it will be very difficult to verify that the client isn't doing something that it isn't allowed to do.

scotty79 9y ago

The difference is that you'd have to have very smart query builder on the front end side that would construct one sql query from combined declared needs of all the front-end components on one page. Then after it gets response (flat as is usual with sql) it would have to split it up and feed to all of the components. On the backend you'd probably need sql query analyser that would figure out which tables and rows query touches to determine if currently logged in user should be able to see this data. So on frontend you need a language in which components can specify their needs (why not graphql?). Next step is asking youself why flatten those to sql before sending them to server only to have it parsed again by the server. It's easier to pass them as grqphql and let server decide if it should respond and draw from data source (or possibly multilple data sources, for example solr and database). Congrats, you invented graphql. Too bad nobody came up with that 15 years ago, this could save a lot of people a lot of trouble.