You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe alternatives you've considered
I considered implementing a layer, between the HTTP request and the Juniper engine, that could convert an ID into a GraphQL query stored within the executable.
That would solve the whitelisting problem and bandwidth usage but wouldn't improve the performance of the GraphQL server compared to just passing the query directly.
For that Juniper would have to expose the parsing and executing as two different function calls. That way I could parse the whitelisted queries at server startup and just reuse those parsed queries time and time again.
Additional context Relay describes persisted queries. Apollo also seems to have support for those.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Persisted queries aim at:
Describe the solution you'd like
Something similar to HotChocolate's persisted queries.
Describe alternatives you've considered
I considered implementing a layer, between the HTTP request and the Juniper engine, that could convert an ID into a GraphQL query stored within the executable.
That would solve the whitelisting problem and bandwidth usage but wouldn't improve the performance of the GraphQL server compared to just passing the query directly.
For that Juniper would have to expose the parsing and executing as two different function calls. That way I could parse the whitelisted queries at server startup and just reuse those parsed queries time and time again.
Additional context
Relay describes persisted queries.
Apollo also seems to have support for those.
The text was updated successfully, but these errors were encountered: