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

Impossible to fetch the context from the graphQLOptions in the resolver #38

Closed
hloos opened this issue Jul 19, 2018 · 6 comments
Closed

Comments

@hloos
Copy link

hloos commented Jul 19, 2018

Playing with the graphql sample provided in the samples of nestjs, I was looking for a way to fetch the context in the resolver in order to extract user token in the header of the request to forward it to other backend services.
Unfortunately, it does not seem to be given as parameter despite its presence in the method signature -> findByOneId.

Here follows the context added to each request and expected in the resolver method call (object ->req.headers)...

  configure(consumer: MiddlewareConsumer) {
    const schema = this.createSchema();
    this.subscriptionsService.createSubscriptionServer(schema);

    consumer
      .apply(
        graphiqlExpress({
          endpointURL: '/graphql',
          subscriptionsEndpoint: `ws://localhost:3001/subscriptions`,
        }),
      )
      .forRoutes('/graphiql')
      .apply(graphqlExpress(req => ({ schema, rootValue: req, context: req.headers })))
      .forRoutes('/graphql');
  }
  @Query('cat')
  async findOneById(obj, args, context, info): Promise<Cat> {
    const { id } = args;
    return await this.catsService.findOneById(+id);
  }

All parameters are undefined except the args one which contains the id.

Moreover, I figured out other unexpected behaviors when adding decorators to the method:

  @Query('cat')
  async findOneById(@Req() req, obj, args, context, info): Promise<Cat> {
    const { id } = args;
    return await this.catsService.findOneById(+id);
  }

Here all arguments are undefined except the args one which contains... the context !! (same issue when replacing the @Req() with @Body())

  @Query('cat')
  async findOneById(@Body() body, @Req() req, obj, args, context, info): Promise<Cat> {
    const { id } = args;
    return await this.catsService.findOneById(+id);
  }

2 decorators allows here to fetch the whole GraphQLOptions in the args parameter (other param still undefined). Same behavior for the signature async findOneById(args): Promise<Cat>.

@hloos
Copy link
Author

hloos commented Jul 19, 2018

So after multiple attempts in debug mode, etc... the this weird parameter values are due to the use of the async keyword (tested in v5.1.0/v5.0.0/v4.61). Without it, it works as expected.

This needs a fix. Let me know if I can help :)

@YemSalat
Copy link

YemSalat commented Aug 6, 2018

Any update on this by any chance?
This makes using decorators for graphql routes pretty much impossible unfortunately

@cschroeter
Copy link

@hloos I don't get your issue. If you like to add something to the context you simply can add information like so

        graphqlExpress(async req => ({
          schema,
          rootValue: req,
          context: { foo: 'bar' },
        }))

If you following the documentation related to nestjs/passport and your GraphQL configuration looks like

       graphqlExpress(async req => ({
          schema,
          rootValue: req,
          context: req,
        }))

You will find yourself an user object in your resolvers.

  @Query('currentUser')
  async currentUser(obj, args, context: Context): Promise<User> {
    const currentUser = context.user;
    return await this.userService.findById(currentUser.id);
  }

@hugoloos
Copy link

@YemSalat the workaround I am using consists in removing the async keyword from the main method (the one annotated with @query) and using another class method (with async keyword) to do the await I need.

@cschroeter your example is quite similar to mine (only the signature method seems different). I am not sure how it can work...

@kamilmysliwiec
Copy link
Member

kamilmysliwiec commented Aug 31, 2018

It should be easy to achieve in the latest module release (which support Apollo v2). Let me know if you face any issue once upgraded.

@lock
Copy link

lock bot commented Apr 25, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants