Skip to content
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

Bring AddArgumentsAsVariables back #4290

Open
klippx opened this issue Mar 9, 2022 · 0 comments
Open

Bring AddArgumentsAsVariables back #4290

klippx opened this issue Mar 9, 2022 · 0 comments

Comments

@klippx
Copy link
Contributor

klippx commented Mar 9, 2022

Is your feature request related to a problem? Please describe.

Version 7.1.5 and earlier had a useful transform AddArgumentsAsVariables, which was removed, apparantly without a good replacement.

Describe the solution you'd like

Bring AddArgumentsAsVariables back! We have a great use case for it in our code base. Other projects in the wild is probably bound to finding it useful as well.

Describe alternatives you've considered

We own AddArgumentsAsVariables ourselves. This however means we have to maintain it and keeping it up to date with the upstream, where we think it belongs, since it is rather complex code.

Additional context

Not really related, but still: If this is merged, we have another cool Transform that can potentially be really useful in a stitching context. Lets descibe it with an example:
We have a setup with BFF (gateway schema stitching) and Services (regular graphql services).
A source schema has a root query which requires userId: Query { transactions(userId: String!) }. However, to avoid forging a user id, on the client, we want to extract this from a server signed JWT token. So what the BFF does is to extract userId from the graphql context (already decrypted and verified JWT token) and injects the userId with whatever value it found there.
On the client side, it consumes the query by simply doing a query: query { transactions { ... } }, from the client side the schema is stripped of userId, it's not even an option. So this makes it way harder for the client to retrieve data that doesn't belong to a verified user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant