3 ms·

Open source lead at Apollo here: The most important thing about the persisted queries approach highlighted in that article, compared to traditional REST archit

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.

ianstormtaylor 8y ago
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.
- underwater 8y ago
  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.

ianstormtaylor 8y ago

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.

underwater 8y ago
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.