Gqlgen: How to access the arguments of a query within the RequestContext Object ?

[dtrckd]

What happened?

Hi there,
When trying to obtain the variables from a request context Object (with graphql.GetRequestContext(ctx).Variables with the following query:

query MyQuery {
  queryNode(filter:{isRoot:true}) {
  name
  }
}

I obtain a empty map.

What did you expect?

map[filter: map[isRoot:true]]

Furthermore, I get the desired result if I use

query MyQuery($args: MyArgs!) {
  queryNode(filter:$args) {
  name
  }
}

{ "args": {"isRoot": true}}

versions

• glqgen : v0.11.3
• go: 1.14.1
  
  
  
  • gqlparser: v2/v2.0.1
  
  

[dtrckd]

Hop,
I apology, I think I misinterpreted the ctx.Variables object semantic, and thus, in the example above, there is nothing abnormal when this field is empty because no variables (graphql data) was provided.

Thus, allows me to rephrase my issue as follow:

Is it possible to access the arguments of a query within the RequestContext Object ?

[isuhendro]

Is it possible to access the arguments of a query within the RequestContext Object ?

@dtrckd I did not do it from RequestContext, instead of that from the 2nd input argument (in below example is input)

func (r *mutationResolver) CreateContact(ctx context.Context, input model.NewContact) (*model.Contact, error) {

input NewContact {
  firstName: String!
  lastName: String!
  accountId: String!
}

type Mutation {
  createContact(input: NewContact!): Contact!
}

[dtrckd]

Tnaks @isuhendro. Yes I can access the input argument from the resolvers but the point is that I need to reconstruct th query as a bytes/string to re-send it to an other Graphql layer. I found it inappropriate to use those inputs because there are typed variable which I need to know before Marshalling them. The difficulties arise because I use a general interface share by several resolver to reconstruct the query, and checking/asserting the type everytimes although I do the same operation for all types which is: "reconstructing the query as a string".

I am currently using graphql.GetRequestContext(ctx).RawQuery as a workaround bur I am not satisfied as I may need to modify the input query in the Business Logic Layer.

[ravisastryk]

@dtrckd I have the same experience with parsing graphql.GetOperationContext(ctx).RawQuery Feel like it is very tedious and error prone. Becomes more complex to deal with when there are multiple arguments/filter inputs in the resolvers and having this custom parser to keep up with schema updates is a nightmare.

@vektah it would be good to access the arguments from the operation context. Any plans to support this feature?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Nope, stale!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Nope, stale.

[mrg0lden]

Will this issue get some love? Is there something that needs to be discussed? Something we can do to give it a little push?