4 ms·

I was very disappointed to find out that GraphQL wasn’t a generalized query language and much more discreet manually defined API, more of a rest api pretending

by donatj 9y ago

I was very disappointed to find out that GraphQL wasn’t a generalized query language and much more discreet manually defined API, more of a rest api pretending to be a query language. That is to say I can only filter in ways the API developer thought of, specifically blessed. Don’t get me wrong, it’s amazingly useful. A process that took us 40 seconds of back and forth with GitHub now takes less than one second.

paulddraper 9y ago
There is a balance between arbitrary queries and predermined queries. One the one hand, you need to be flexible. On the other, allowing any query no matter how horrendous can be bad for a public API. IMO, GraphQL strikes the perfect balance for a public API.
obi1kenobi 9y ago
I was very disappointed with the same thing! However, it is very easy to get rid of the resolver-based execution model and turn it into a generalized graph query language. We've done that at my company and it's been working well for us -- here's our blog post: https://blog.kensho.com/compiled-graphql-as-a-database-query-language-72e106844282 https://blog.kensho.com/compiled-graphql-as-a-database-query... We also open-sourced the GraphQL compiler code that lets us write graph queries: https://github.com/kensho-technologies/graphql-compiler https://github.com/kensho-technologies/graphql-compiler pip install graphql-compiler
gnarbarian 9y ago
Have you considered trying orientdb? http://orientdb.com http://orientdb.com
hirundo 9y ago
I'm implementing filtering in a graphql api now, on a sql backend (a fixed constraint). We decided we just can't support arbitrary filtering. Full table scans don't scale, and an index for every column is costly. So we'll support it only on indexed columns and add indexes selectively. If graphql did require arbitrary filtering it would be useless to us at this point.
michaelsbradley 9y ago
Have you looked into PostGraphQL? https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql
- DigitalJack 9y ago
  That looks like a nice tool for generating a graphql schema. Resolving functions are still required.
  - sharatv 9y ago
    Resolving functions are included. I'm using it to power a fully-functional GraphQL service backed by a PostgresQL database. There's a newer version at https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ by the same author.
cvburgess 9y ago
Check out [0] and similar projects out there. GraphQL is a query language. It doesn't have to be used for APIs - the Apollo team is using it for state management [1] and others are using it to handle all sorts of non-API data. That being said, it is a Facebook technology released in the context of APIs and it is only three years (publicly) old, so naturally, that is where you are going to see the majority of usage. [0] https://github.com/apollographql/graphql-anywhere https://github.com/apollographql/graphql-anywhere [1] https://github.com/apollographql/apollo-link-state https://github.com/apollographql/apollo-link-state
acjohnson55 9y ago
As other folks have mentioned, there's no reason this has to be the case. It's totally possible to take a basic GraphQL schema and programmatically enhance it with generated filters based on field types. Graphcool offers this. I think it makes a much better platform for this than REST. My guess is that eventually, standards will emerge. We can already see it in Relay, with their connection pattern for pagination.

by donatj 9y ago

paulddraper 9y ago

There is a balance between arbitrary queries and predermined queries. One the one hand, you need to be flexible. On the other, allowing any query no matter how horrendous can be bad for a public API. IMO, GraphQL strikes the perfect balance for a public API.

obi1kenobi 9y ago

I was very disappointed with the same thing! However, it is very easy to get rid of the resolver-based execution model and turn it into a generalized graph query language. We've done that at my company and it's been working well for us -- here's our blog post: https://blog.kensho.com/compiled-graphql-as-a-database-query-language-72e106844282 https://blog.kensho.com/compiled-graphql-as-a-database-query... We also open-sourced the GraphQL compiler code that lets us write graph queries: https://github.com/kensho-technologies/graphql-compiler https://github.com/kensho-technologies/graphql-compiler pip install graphql-compiler

gnarbarian 9y ago

Have you considered trying orientdb? http://orientdb.com http://orientdb.com

hirundo 9y ago

I'm implementing filtering in a graphql api now, on a sql backend (a fixed constraint). We decided we just can't support arbitrary filtering. Full table scans don't scale, and an index for every column is costly. So we'll support it only on indexed columns and add indexes selectively. If graphql did require arbitrary filtering it would be useless to us at this point.

michaelsbradley 9y ago

Have you looked into PostGraphQL? https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql

DigitalJack 9y ago
That looks like a nice tool for generating a graphql schema. Resolving functions are still required.
- sharatv 9y ago
  Resolving functions are included. I'm using it to power a fully-functional GraphQL service backed by a PostgresQL database. There's a newer version at https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ by the same author.

cvburgess 9y ago

Check out [0] and similar projects out there. GraphQL is a query language. It doesn't have to be used for APIs - the Apollo team is using it for state management [1] and others are using it to handle all sorts of non-API data. That being said, it is a Facebook technology released in the context of APIs and it is only three years (publicly) old, so naturally, that is where you are going to see the majority of usage. [0] https://github.com/apollographql/graphql-anywhere https://github.com/apollographql/graphql-anywhere [1] https://github.com/apollographql/apollo-link-state https://github.com/apollographql/apollo-link-state

acjohnson55 9y ago

As other folks have mentioned, there's no reason this has to be the case. It's totally possible to take a basic GraphQL schema and programmatically enhance it with generated filters based on field types. Graphcool offers this. I think it makes a much better platform for this than REST. My guess is that eventually, standards will emerge. We can already see it in Relay, with their connection pattern for pagination.