3 ms·

Thinking about the problems with client-side SQL seems informative[0]: * Security; allowing evaluation rather than a describing results. * DDL; Data Structure

by irq-1 10y ago

Thinking about the problems with client-side SQL seems informative[0]: * Security; allowing evaluation rather than a describing results. * DDL; Data Structure and Types need to be learned out-of-band. Ideally we want a sort-of interactive INFORMATION_SCHEMA over http, so our tools can inform us about types/structure and we always have updated info as we write queries. * Performance; Stored Procedures (server-side) protect against a client making poor joins; ORMs requesting too much data, etc... * Info about Security: client side SQL doesn't know what rights it has, or you could say that a client account can't see the big picture of DDL. The understanding of rights is all communicated through non-API means. * Info about Performance: clients don't know rate limits, current system load, what system admins consider reasonable data sizes or reasonable analytic calculations, etc... I don't know what GraphQL does for each of those issues, but I'd love to hear. [0] I recently setup InfluxDB which has a (private) web interface that takes raw SQL-ish, and it's so convenient.

brandur 10y ago
So I think it's a bit of a misconception that GraphQL is going to essentially map to SQL in the backend. Essentially, it's up to the service provider to decide what query paths and mutations are available in GraphQL, and design their schema accordingly. So for example, if you allowed "comments" to be queried within a "user", you'd make sure that users could be looked up efficiently by their ID, and that comments could be loaded in bulk efficiently based on user ID. You'd also make sure that your implementation for both those operations is secure. It's not too dissimilar to REST in that you're still very much designing what your API should look like and not exposing anything else.
djmashko2 10y ago
I cover a lot of these thoughts in my post about misconceptions about GraphQL coming from REST here: https://dev-blog.apollodata.com/graphql-the-next-generation-of-api-design-f24b1689756a#.ph8196t2j https://dev-blog.apollodata.com/graphql-the-next-generation-...

by irq-1 10y ago

brandur 10y ago

So I think it's a bit of a misconception that GraphQL is going to essentially map to SQL in the backend. Essentially, it's up to the service provider to decide what query paths and mutations are available in GraphQL, and design their schema accordingly. So for example, if you allowed "comments" to be queried within a "user", you'd make sure that users could be looked up efficiently by their ID, and that comments could be loaded in bulk efficiently based on user ID. You'd also make sure that your implementation for both those operations is secure. It's not too dissimilar to REST in that you're still very much designing what your API should look like and not exposing anything else.

djmashko2 10y ago

I cover a lot of these thoughts in my post about misconceptions about GraphQL coming from REST here: https://dev-blog.apollodata.com/graphql-the-next-generation-of-api-design-f24b1689756a#.ph8196t2j https://dev-blog.apollodata.com/graphql-the-next-generation-...