Comment by ianstormtaylor | Hacker News Reader

Comment by ianstormtaylor | Hacker News Reader

Quiver looks interesting, congrats on launching! It seems like it will be very useful for internal GraphQL APIs.

It does bring up something that I think the GraphQL community hasn't really addressed well yet though... Part of the way Quiver works is that it only allows pre-defined queries which can then be compiled ahead of time.

> Only allow certain queries from a document store.

This is becoming a common response for how to make GraphQL performant and "secure". [1]

But this solution only works for internal APIs. If you're trying to expose a public GraphQL API it isn't viable.

Not only that, but to sync these "persisted" queries from the client to the server, lots of the persisted query tools require you to hard-code GraphQL queries as `.graphql` files in your repository... effectively re-inventing hard-coded REST responses. Except with an extra build process between the client and the server for each new deploy. You no longer really have each component requesting exactly what it needs.

The more research I do into GraphQL, the more it seems like the promise of "query anything" that libraries are selling is often discarded when you get to actual implementation. And you end up with a situation that is much more similar to REST/HTTP than originally intended.

[1]: https://dev-blog.apollodata.com/persisted-graphql-queries-wi...

Open source lead at Apollo here:

The most important thing about the persisted queries approach highlighted in that article, compared to traditional REST architecture, is that the queries live in your _client_ codebase. So the frontend developers write the shape of the data, rather than backend folks hardcoding it in like with endpoints.

I would say that at the current moment only a small minority of GraphQL users (based on our experience) are using persisted queries, and running in production without that is just fine with good performance and security. A simple approach like query timeouts, or discarding queries based on complexity, goes a long way here.

Thanks for the response!

I agree, having queries live in the client is a great goal for DX on the frontend. The ideal being to have them co-located right with the components that need the data. But the issue is that these kinds of solutions are often presented without discussing their tradeoffs. From the article:

> Because persisted queries are static by definition, they also give you the possibility of optimizing execution on the server for specific queries, for example by hand-crafting a highly efficient database query.

Well, that's a bit harder when the client controls the queries and they're automatically "recompiled" on each new deploy, because now you're optimizing a moving target that could change dramatically with little notice. It's not really a benefit, since it's such a fragile situation to be relying on in the first place.

Persisted queries also kind of make co-location of queries with components a non-starter. Maybe Apollo doesn't want to allow co-located queries, which could be an okay decision, but isn't really discussed much as a tradeoff.

And then it doesn't solve the larger issue that these solutions don't work for public-facing APIs. So you end up having to solve the same issues (eg. bandwidth, security, caching) again in an entirely new way.

I think it's something the community will need to address if public-facing GraphQL APIs are going to flourish.

Relay Modern allows co-located queries with components.

I don’t understand your concerns about performance or security. GraphQL should only expose the fields you can fetch in a fast and safe way. Optimise the field lookups; not the whole query execution.

A deeply nested GraphQL request is no worse than a series of REST fetches.

Reply on news.ycombinator.com