Persisted query support in graphql-java #2013
Conversation
| * @return an instance of {@link PreparsedDocumentEntry} | ||
| */ | ||
| PreparsedDocumentEntry getDocument(ExecutionInput executionInput, Function<ExecutionInput, PreparsedDocumentEntry> computeFunction); | ||
| PreparsedDocumentEntry getDocument(ExecutionInput executionInput, Function<ExecutionInput, PreparsedDocumentEntry> parseAndValidateFunction); |
There was a problem hiding this comment.
This is a much better name for the callback parameter because that's what it does
| } | ||
| return Optional.empty(); | ||
| } | ||
| } |
There was a problem hiding this comment.
Later if there is a V2, we can update this
There was a problem hiding this comment.
The change to ExecutionInput.java is all that is needed. I would be hesitant to add any Apollo-specific classes into this code. I think it should be just a part of the documentation or a small library separate from graphql-java.
For similar reasons, this library does not support Apollo-specific scalars such as Upload.
|
Too bad it was decided to become so Apollo-dependent. It will cause issues if another client library pops up and uses a different persisted query mechanism. |
It's not Apollo dependent at all. People have always been able to build out a This adds an abstract class We have some Apollo specific code already like Some one can create new implementations, either from first principles or from extending the Honestly I am not sure on the tone of your reply. At best it seems unappreciative and snarky. |
|
@bbakerman Thanks for the explanation. I still think that Apollo-specific code could be in a separate library as not everyone uses Apollo. But since as you say there already was some Apollo-specific code even before this PR it's too late to change that. |
|
@bbakerman Thanks for the work. I have a question, now that we have extensions and client may just pass extension (hash) w/o a query, shouldn't it allow |
|
Now that is a good question and one I think Andreas M should also have a
think about
…On Fri, 19 Feb 2021 at 05:23, Mohamad Z ***@***.***> wrote:
@bbakerman <https://github.com/bbakerman> Thanks for the work. I have a
question, shouldn't it allow query (in ExecutionInput) to be null now
that we have extensions and client may just pass extension (hash) w/o a
query.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2013 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMVWSLISKM2G3QE4KXOBS3S7VLIHANCNFSM4QOA4A5A>
.
|
This adds the basis for persisted query support in graphql-java.
In short consumers need to have their own cache implementation to be truly useful. The
InMemoryPersistedQueryCacheone is too bare bones for production use at scale, as its not memory constrained.ApolloPersistedQuerySupporthas been provided which can read persistent query ids from the input extensions.See #1972