Title
m
matty
09/14/2017, 10:12 PM@johhansantana that would not be a Good Thing™ ... as the client sending which fields its using is an advantage down the line, when you're trying to understand which fields are still in use (e.g. if you want to deprecate a field, you want to know first if people are still querying for it)
a
agartha
09/14/2017, 10:43 PM@matty I have to politely disagree. I think it would actually be a Good Thing :TM:. And so do the folks at Apollo, who have created persistgraphql, a way to define queries client-side, reference them on the server, and call them from the client by id.
m
matty
09/14/2017, 10:48 PMhm, this seems like a trade-off but in terms of future maintainability and performance I'd avoid the use of persisted queries
if the query is co-located with the client (and assuming the query is not requesting fields that it does not actually use), there are a few advantages:
1 - can avoid computing expensive fields if they were not explicitly requested by the client
2 - can monitor request activity per field, and deprecate/cleanup the graphql interface if active clients are no longer request a particular field/s
im sure there's a best of both worlds scenario here, perhaps the creation of persisted queries based on iterative builds
but the idea of persisted queries on the server with no clue as to actual client-side usage, imho, it appears to undo some of the promise of graphql
Ah - this is the best of both worlds here, a comment by the author of the medium post you linked to: "A build tool that actually extracts the queries at build time probably has to exist in some capacity."
👍🏻 1
actually having now just read the whole article, it seems persisted queries are actually rooted in co-located queries already - which is fantastic!
going back to the original question from @johhansantana - persisted queries (which still require co-located queries in the client source code) don't exactly solve the problem mentioned here.. where they don't want to recreate the same queries in each client type (mobile, web, etc) ... a possible persisted queries + private npm package solution might work best here?
j
johhansantana
09/14/2017, 11:39 PM@matty the idea behind my question is that the business logic is dealt once and done with it, so that our frontend engineers only have to query the same endpoint where we know it already works and not recreate the queries/mutations and having to test that everything works on each client.
the persistent queries like idea for limiting the queries I open to the public might be another thing that might be beneficial for some use cases
d
dankent
09/15/2017, 8:18 AMI agree with @matty on this - for me, the big benefit of GraphQL over REST endpoints is that the decision on what data to fetch is made at the point where the data is being used. Doing it this way has made me much more productive. Of course, others may well have very difference use cases.
If you only want clients to access a fixed set of queries, why not just use REST endpoints?