Hacker News Reader

Comment by djmashko2 | Hacker News Reader

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.

View on HN

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