graphql-typed-document-node
graphql-typed-document-node copied to clipboard
dotansimha
Handling persisted queries and mutations
@dotansimha Hi. Awesome work with this. While I am able to properly generate types for all the queries and mutations with this, I was wondering how you would handle type generation for persisted queries and mutations with this.
I want to persist queries and mutations in the server for security reasons but I still want to be able to generate types on the client side for the operation documents which has been persisted.
Any guidance on how I can go ahead with this would be great. Thanks.
Digged a bit more. Looks like I can have the queries and mutations both on the client and server and use this: https://github.com/valu-digital/graphql-codegen-persisted-query-ids to generate the hash for queries and also generate types for the same using codegen on the client.
But, I won't be passing the typedDocumentNode to the client query but the hash which means that I won't be getting the response to be typed as expected. Any workarounds? Or should I set the return types manually by using the generated types?
Noticed a project which uses it - https://github.com/DomHynes/graphql-pet-store/blob/master/codegen.yml but does not use typedDocumentNode though
Or am I just thinking too much 😅 ? Since the typedDocumentNode is passed anyways to apollo client along with the pre generated hash, I hope it should also be able to return me the types on the client side.
Hi @tvvignesh I think this might need a bit more exploration. I guess it all depends on how you setup persisted queries, and what you need to pass eventually (during development and during production) to your client. Persisting queries means that you needs to assign a hash to your operation, and use that instead of the actual operation, and from the point of view of typed-document-node - it doesn't really matter.
Can you please share how do you do persisted queries? what is the flow you are using? Are you compiling your operations in build time? or before?
@dotansimha Hi again. To be honest, am just building it, so open to any recommended approach. After some digging, I thought I should generate the hash of the queries at build time using https://github.com/valu-digital/graphql-codegen-persisted-query-ids and also generate the types for it using codegen and typeddocumentnode and then use the hash on the server side to do whitelisting and other things.
But I guess to do that I should always have my persisted queries also in the client always and cannot delete it at any point. Still wondering if this is the right approach. Any recommendations?
@tvvignesh that's a great question :) I guess generating hash at build time is great, but it depends on how it's done on that plugin.
I would imagine something like that for the backend:
- Generate hash based on operation SDL
- Allow backend to know about those hashes as a whitelist
For the frontend, it can be:
- Runtime that prints the
DocumentNode(or,TypedDocumentNode) and hashes it before running. - Or, a Babel transformer that would replace GraphQL
DocumentNode(or,TypedDocumentNode) with the hash at build time.
What do you think? does it makes sense?
@dotansimha From the looks of it, while it makes sense, I was going through https://www.apollographql.com/docs/studio/operation-registry/ as well where Apollo persists the mutations on the server side (its proprietary though and am not using it) but what they do is generate the hash at runtime while https://github.com/valu-digital/graphql-codegen-persisted-query-ids generates the hash at build time.
So, I guess either way the queries should be available on the client always. Maybe I will try it and let you know.
@dotansimha Just wanted to update you. Had parked the persisted queries exercise sometime back and won't be working on it for quite some time (Working with non-persisted queries to get things done as of now).
You can close this issue or leave it open - Will try it again after I am done with other things. Thanks.