Persisted operations + GCS integration improvements

[rickbijkerk]

A MR with small tweaks i had to do to make persisted operations work together with a GCS bucket
changes include:

• No longer forwarding 'operationName'
• Minor tweaks in documentation regarding fetching from GCS bucket
• Properly reading the gcs downloaded files from disk by including the directory

[ldebruijn]

What is the need for implementing https://www.apollographql.com/docs/react/api/link/persisted-queries/ the Apollo Persisted Queries manifest? It's a proprietary format only supported by the Apollo Router and go-graphql-armor aims to be agnostic to these formats? Any reason why persisted operations cannot be supplied in the format as described in: https://github.com/ldebruijn/go-graphql-armor/blob/main/docs/persisted_operations.md#parsing-structure ?

[rickbijkerk]

Let me work on the failing tests

[ldebruijn]

If you check out the following resources these expect & generate perstisted operations in the already implemented map[string]string format, and not the Apollo PO specification.

https://the-guild.dev/graphql/codegen/plugins/presets/preset-client#persisted-documents
https://github.com/graphile/persisted-operations

[rickbijkerk]

If you check out the following resources these expect & generate perstisted operations in the already implemented map[string]string format, and not the Apollo PO specification.

https://the-guild.dev/graphql/codegen/plugins/presets/preset-client#persisted-documents https://github.com/graphile/persisted-operations

The problem with that is that the hashes generated by the tooling above dont seem to match the hashes that apollo seemed to generated. Most likely due to new lines added in places and we didnt want to go there to fix it. Which is why we opted for this approach.

Another solution however (and i think more in line with your view) would be to do some pre-processing before pushing it to the bucket so that we have a hash,query pair like you described above, without any formatting leaking into this project. Which might be the nicer option as it also gives us the freedom to use whatever client we want as long as the generated hashes match what a client sends.
This also doesnt attach us too much to apollo, which is a pro :)

Thoughts?

[ldebruijn]

Yes I do prefer the simpler non-vendor option of map[string]string and optionally having pre-processing before uploading to the bucket. This removes tying this solution to specific (set of) clients/generators and since the format is extremely simple anyone can use it.

[ldebruijn]

Could you add a description to your MR and update the title as it no longer touches Persisted Ops in that sense. That way it'll show up correctly on the generated changelog

[rickbijkerk]

Could you add a description to your MR and update the title as it no longer touches Persisted Ops in that sense. That way it'll show up correctly on the generated changelog

sure thing, will look into that tomorrow!

[ldebruijn]

Perfect, thanks for your contribution @rickbijkerk !