Feature Request: Support Apollo Persisted Queries on Server

[FelixPSch]

It would be great if the server supported Apollo Persisted Queries.

When using persisted queries, requests may include only an extensions field containing the hash of the query, without the query itself. Currently, when such a request is executed, the io.smallrye.graphql.execution.ExecutionService returns an error indicating that the query is missing.

The graphql-java library already supports persisted queries via graphql.execution.preparsed.persisted.ApolloPersistedQuerySupport. But it's not possible to use this since the server throws the error earlier.

[jmartisk]

Thanks for the report, I'm again learning something new (so sorry that I'm not very familiar with this).
What do you envision as the source where to find persisted queries? Should we support attaching a persisted-query-manifest.json to the app, or allow to define the queries via annotations that are scanned during build time?

[FelixPSch]

Thanks for checking it out. I think attaching a persisted-query-manifest.json would work. Scanning the annotations wouldn't give information about the selected properties of a query which would be needed to calculate the hash, right?

[jmartisk]

We could add an annotation like

@PersistedQuery(
  body = "query GetItem { thing { __typename } }",
  name = "getItem",
  type = QUERY
)

from this, I guess Quarkus could calculate the hash (I haven't checked how exactly the hash should be calculated, but I would assume this is enough information). Quarkus would then generate a persisted-query-manifest.json from this, including the hashes (so that the developer doesn't have to calculate them manually) and that file could then be used and imported on the client side (AFAIU the client needs to consume the manifest because this information isn't contained in the regular GraphQL schema).

Support in the client-side of smallrye-graphql would be another matter.

This annotation could be placed pretty much anywhere in the app's codebase, Quarkus would find it during build.

I hope I'm not wildly misunderstanding things (I just briefly looked at the documentation) but I guess this could work

[FelixPSch]

Yes, I think that should work and would be enough information to calculate the hash.

If Quarkus would generate the JSON file from the annotations, maybe it would work to support both supplying a JSON file and generating it with annotations?

In our case we use the apollo-client and we would generate the JSON file with that. The server would then get access to that file and could use it to replace the hash with the respective query. The apollo-client supports replacing the query with the hash seamlessly, so the developer can write out the query, and at runtime the hash would be sent instead.

I don't know how development of other clients would work if the JSON file is generated by the server, though. Would the developer of the client need to check the JSON file for which queries are supported by the server?

[jmartisk]

Yes I guess we could support both annotations (in which case we would generate the manifest) AND consuming an already provided manifest during build.

I don't know how development of other clients would work if the JSON file is generated by the server, though.

IIUC an Apollo client needs to consume the file before it is initialized (a smallrye-graphql client could implement something similar), so if you generate the manifest on the server, you would need to distribute it to consumers somehow

[FelixPSch]

That sounds good!

[jmartisk]

Ok. The hard part is finding resources to actually implement this..
I can't make promises myself because I'm quite busy. If anybody wants to do it, I'm happy to provide support over chat or google meet. Otherwise I'll look at it, but I don't know when.