Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server-Stored Query Documents #5

Open
hlship opened this issue May 15, 2017 · 5 comments
Open

Server-Stored Query Documents #5

hlship opened this issue May 15, 2017 · 5 comments
Assignees
Milestone

Comments

@hlship
Copy link
Member

hlship commented May 15, 2017

It would be nice if there was an overall approach to server-stored query documents. This is a bit tricky, since we need to abstract over how such documents are persisted on the server and exposed in a cluster. But at the root of it, the client should be able to send a request that simply identifies the query by some form of ID, and optionally supply variables and/or operation name. This can greatly reduce the size of request sent to the server and slice a chunk of processing time out of handling the request, when the parsed query is already cached in memory.

@jimmyhmiller
Copy link
Contributor

One simple approach might be to allow passing an interceptor as an option. That way you can doing any computation you want before the query is parsed. Might be a little too powerful, but it should definitely work.

It doesn't try to solve the problem of persistence, but it leaves it open how you want to fetch the queries. If you need to do it asynchronously, you can just return a channel like any interceptor. Here's a quick proof of concept. Might be better just to make it a function and maybe only pass it a subset of data instead of the whole context.

@hlship
Copy link
Member Author

hlship commented May 19, 2017

An interceptor is exactly what I was thinking and basic work to support looking up a parsed query by name, including a hash fingerprint.

@hmaurer
Copy link

hmaurer commented Jul 6, 2017

Has there been progress made on this? @hlship you mentioned on Slack that you are working on making the interceptor chain more malleable; I assume it will solve this issue?

@hlship
Copy link
Member Author

hlship commented Oct 16, 2017

Since we don't yet use this in the Walmart code, we don't have a good battle-tested solution for this. I'll bring it up internally ... I'd like to see some support for this, but we need some server-side strategy and infrastructure to abstract from.

@hlship hlship self-assigned this Jun 27, 2018
@hlship hlship added this to the 0.10.0 milestone Jun 27, 2018
@hlship hlship modified the milestones: 0.10.0, 0.11.0 Jul 20, 2018
@hlship hlship removed this from the 0.11.0 milestone Nov 13, 2018
@hlship hlship changed the title Server-Side Query Documents Server-Stored Query Documents Dec 4, 2018
@hlship
Copy link
Member Author

hlship commented Dec 4, 2018

We've been interating on this internally; the concensus was to have yet another endpoint for stored queries. A full implementation also includes a restful POST endpoint for creating queries, but that's likely beyond what we can supply in library code (as it involves authentication and other details that are very application specific).

@hlship hlship added this to the 0.14.0 milestone May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants