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
Add support for PreparsedDocumentProvider #50
Comments
This looks interesting. I don't think we've looked at Since I don't know anything about |
The only issue I see with this approach would be if a schema change occurs in combination with using a It seems a bit of an unlikely edge case though since this issue would only occur if |
Thanks for the details! I’ll look into this in detail soon. |
My understanding is that the PreparsedDocumentProvider avoids parsing the query over and over again... you can set it on a cache that you can control how long it lives:
I have found this dramatically improves query time execution, since in our application our query fields are hundreds if not thousands of bytes using complicated schema objects. I am evaluating using DGS and would really NEED this capability. I see in the DGS codebase, you are rebuilding the GraphQL object for each execution.. the pre-parsed document cache, would have to be a shared component (bean) for it to have any effect, creating it each time from scratch would serve no purpose... note: the caching really only works with query formulated like this: query($cat: String, $fts: String, $offset: Int, $limit: Int) { |
Just as a note, your client query generators in the code-gen package do NOT create queries that could be cached, the queries created need to be of the format above where the variables are passed in. The parsed query can be cached because it does NOT have the real variables in it. The code-gen creates a query with the specific variables in the actual query. Do you have an ETA on when this feature can be available? |
The way I tried to implement this was by expecting a For instance using graphql-dgs-example-java if
Using the default no-op PreparsedDocumentProvider if schema reloading is true will make this scenario very unlikely. But to ensure that the cache doesn’t have any items that may no longer be valid, I think a few choices are either:
I could spend some time to submit a PR for the first option that simply leaves it disabled and writes a warning out to the log since that should be a simple change to what I already have worked out. The other option looks a bit more complex since the state of schema reloading would need to be tracked and a way to clear a PreparsedDocumentProvider would need to be introduced. Any other thoughts or suggestions are appreciated! |
👋 Hi, y'all. I'd like to contribute some thoughts to this. I have two preliminary takes on this. DefaultDgsQueryExecutor (
...
private val graphqlTransformer: Consumer<GraphQL.Builder> = Consumer { }
) The implementor can choose to use the But on the topic of passing a PreparsedDocProvider into the DgsExecutor. fun provider(): PreparsedDocumentProvider That would require that the executor class has a private defaultSchema: GraphQLSchema,
defaultPreparsedProvider: PreparsedDocumentProvider,
...
private val preparsedDocumentFactory: DgsPreparsedDocumentFactory,
private val reloadIndicator: ReloadSchemaIndicator = ReloadSchemaIndicator { false } This feels like too much to be doing just so we can make sure a reload is properly handled for a provider. |
I like the idea of having the ability to override the Default Preparsed DocumentProvider with your own bean, if that is possible... if the ReloadSchema thing is in force, that is counter-intuitive to the PreParsed Document cache, so if it is reloading the schema, then by default, use the NoOp document provider? make it so it's either 1 OR the other?? |
Thanks everybody who is taking a look at this!!! |
Hi @jregistr Any news about this integration ? I'm interested to contribute. Thanks |
👋 Somewhat related... I'm doing some experimenting with adding APQ support currently. I'd greatly appreciate some feedback. |
Hi everybody, so I was following up on progress on this ticket. So the Graphql-java/graphql-java that has this fix is in V17.0+ release and I see no changes in the Netflix code to support this. The Graphql-java V17.+ release is a breaking change, and I attempted to bootstrap it into an existing DGS deploy. The breaking changes are to the GraphQLArgument because a new InputStateValue object got introduced. The Apollo-federation library schema printer code needs to be updated... that library is also dependent on graphql-java v 16.x, so it needs patched.. I suppose I could file a ticket to have them update their library as well (which I will do) ...graphql-java v17.0 seems to have performance improvements as well, which would be great to have What is your plan for integration of the new version? After I manually fixed the Apollo-federation library, which was basically patching the schema printer which was easy because the graphql.SchemaPrinter.java had the right code, everything did work in a test playground, so didn't seem to be a breaking change, but would need testing. I filed a request: They already have done the work, it hasn't been merged or released: apollographql/federation-jvm#122 Since I see Paul was commenting on the Apollo-federation ticket, it appears DGS is awaiting this as well! |
Yes, we're waiting for the As soon as there is a release, we'll update the framework to the new version. |
@paulbakker does that mean the new release will have some sort of support for the PreparsedDocumentProvider or will the new Apollo library inherently support the persisted query extension? I wasn't quite sure by reading this. |
Sorry, my comment was just about the |
I finally added support for providing a |
Merged in: PR #583 |
…uration. (#1) Please refer to Netflix#50. Support of PreparsedDocumentProvider was added through Netflix#583. Above PR added it to DefaultDgsReactiveQueryExecutor but missed changes in DgsWebFluxAutoConfiguration. In this PR, we are fixing that so that WebFlux application can define own implementation PreparsedDocumentProvider.
Dont work the example: `@Configuration
} |
Bean should be of type PreparsedDocumentProvider. Above code use PreparsedDocumentEntry. |
I’ve started exploring an implementation https://github.com/bergerandrew/dgs-framework/tree/query-caching but since a PreparsedDocumentProvider can return existing entries without re-running query validation, it is incompatible with schema reloading or custom ReloadSchemaIndicator implementations.
Are there any plans to add support for query caching using
PreparsedDocumentProvider
?The text was updated successfully, but these errors were encountered: