4 ms·

Ignorant here: why not just use a subset of SQL? It needs a filter and it definitely needs to be applied to a limited, custom view of the actual underlying dat

Ignorant here: why not just use a subset of SQL? It needs a filter and it definitely needs to be applied to a limited, custom view of the actual underlying data, but… that’s what you have to do anyway with a REST or GraphQL API. By the time you’re done making your REST/GraphQL API “really flexible” couldn’t you just build an SQL filter? All the APIs I used to so far are so limited. For example there’s no easy way to query multiple posts at once on GitHub’s GQL while that could have be an extremely simple `SELECT title FROM issues WHERE id IN (13,57)`

Lapsa 7y ago
It's bad to write SQL queries on the client side :-)
- caseymarquis 7y ago
  Exactly. That's why we needed a new tool that does exactly the same thing, but allows us to say we're doing something different. </s> I have always had the impression that graphql was built for a problem Facebook has, but that most of the rest of us don't (numerous complex backend (some non-SQL) data sources and highly independent frontend teams moving very quickly). As I work in an environment where there are no frontend vs backend developers, and we have a single SQL database, graphql is a neat tool which solves some problems I will probably never have.
  - true_religion 7y ago
    Well I use graphql to get data stored in Redis, ElasticSearch or is just calculated on the fly. It’s just an api endpoint.
- why-oh-why 7y ago
  Is it? Or is it just bad to pass unsanitized SQL queries? Because that’s the only issue I think. GraphQL seems effectively an input data sanitizer.
pier25 7y ago
Or you could use a zero coding backend solution on top of a database like Hasura or PostGraphile.
- why-oh-why 7y ago
  Just like there’s Hasura there could be a zero-coding tool that does the same for SQL. I’m not arguing that the average developer should write an SQL query sanitizer but just that what companies are investing into GQL could be invested into something more flexible. Sometimes we discard tools and ideas because at some point in the past they were poor or bad practice. See PHP and IE.
- hootbootscoot 7y ago
  postgrest http://postgrest.org/en/v6.0/ http://postgrest.org/en/v6.0/

Lapsa 7y ago

It's bad to write SQL queries on the client side :-)

caseymarquis 7y ago
Exactly. That's why we needed a new tool that does exactly the same thing, but allows us to say we're doing something different. </s> I have always had the impression that graphql was built for a problem Facebook has, but that most of the rest of us don't (numerous complex backend (some non-SQL) data sources and highly independent frontend teams moving very quickly). As I work in an environment where there are no frontend vs backend developers, and we have a single SQL database, graphql is a neat tool which solves some problems I will probably never have.
- true_religion 7y ago
  Well I use graphql to get data stored in Redis, ElasticSearch or is just calculated on the fly. It’s just an api endpoint.
why-oh-why 7y ago
Is it? Or is it just bad to pass unsanitized SQL queries? Because that’s the only issue I think. GraphQL seems effectively an input data sanitizer.

pier25 7y ago

Or you could use a zero coding backend solution on top of a database like Hasura or PostGraphile.

why-oh-why 7y ago
Just like there’s Hasura there could be a zero-coding tool that does the same for SQL. I’m not arguing that the average developer should write an SQL query sanitizer but just that what companies are investing into GQL could be invested into something more flexible. Sometimes we discard tools and ideas because at some point in the past they were poor or bad practice. See PHP and IE.
hootbootscoot 7y ago
postgrest http://postgrest.org/en/v6.0/ http://postgrest.org/en/v6.0/