Hacker News Reader

Comment by donatj | Hacker News Reader

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.

View on HN

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...

We also open-sourced the GraphQL compiler code that lets us write graph queries: https://github.com/kensho-technologies/graphql-compiler

    pip install graphql-compiler

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.

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.

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 [1] https://github.com/apollographql/apollo-link-state

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.

Have you looked into PostGraphQL?

https://github.com/postgraphql/postgraphql

That looks like a nice tool for generating a graphql schema. Resolving functions are still required.

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/ by the same author.

Have you considered trying orientdb?

http://orientdb.com

Reply on news.ycombinator.com