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

"this" context or request data is unavailable from apolloKoa() #144

Closed
saeho opened this issue Sep 16, 2016 · 16 comments
Closed

"this" context or request data is unavailable from apolloKoa() #144

saeho opened this issue Sep 16, 2016 · 16 comments

Comments

@saeho
Copy link

saeho commented Sep 16, 2016

Currently I cannot see the request data from:

Router.post('/graphql', apolloKoa(() => {...}));

It doesn't seem possible to get the request headers from apolloKoa().

@mikeifomin
Copy link

mikeifomin commented Sep 17, 2016

Koa 2 is supported I guess.

So headers contains in ctx object.
Related issue
#139

And yes for now there is no way to pass the context data into options function.
In express integration, for example, user(and other middleware state data) passed normal - see GitHunt example

@helfer
Copy link
Contributor

helfer commented Sep 19, 2016

@saeho @mikeifomin What's the best way we can fix your problems?

cc @HriBB

@saeho
Copy link
Author

saeho commented Sep 19, 2016

Currently even though Apollo-Server supports Koa2, it really doesn't.

In order to allow authentication with each GraphQL query, we need to be able to pass some sort of token or auth info to the POST request's header. Then I need to be able to do something with that header info or pass it into the context. Currently Koa2 implementation of Apollo-Server does not make this possible.

Thus, Apollo-Server is unusable in Koa2.

@helfer
Copy link
Contributor

helfer commented Sep 19, 2016

@saeho Right, so how do we make it useable? Having access to it in the options function would be enough, right? I thought that was already the case, but I might be mistaken.

@saeho
Copy link
Author

saeho commented Sep 19, 2016

I stopped using ApolloKoa few days or a week ago but as far as I remember there was no way for me to see the header from the options function. So even though the ability to use a function to generate the options was there, I couldn't do anything with it.

@mikeifomin
Copy link

@helfer
mikeifomin@6584ac4

@helfer
Copy link
Contributor

helfer commented Sep 19, 2016

@mikeifomin ok, I think we could just pass ctx instead of ctx.request as the only argument.

@mikeifomin
Copy link

mikeifomin commented Sep 19, 2016

@saeho I'm working on app written with the KoaJS 2. And with the easy fix everything is ok and I have more cleaner resolvers code with async/await style.

@mikeifomin
Copy link

@helfer your proposal looks better in case of "clean api". But it will break compatibility.

@helfer
Copy link
Contributor

helfer commented Sep 19, 2016

@mikeifomin true, although I think that's acceptable at this point. If you could make a PR, that would be great!

@migueloller
Copy link

@helfer and @saeho,

Looking forward to the change from just passing request to passing ctx. For now, this small change should work, though:

Router.post('/graphql', (ctx, next) => apolloKoa(() => {...})(ctx, next));

That way you can use ctx however you want (e.g., pass it as GraphQL context) until this PR gets done.

@HriBB
Copy link
Contributor

HriBB commented Sep 21, 2016

Hey. Sorry for the late reply, I'm really busy these days.

So if I understand this correctly, all that needs to be changed to resolve this issue is to pass ctx instead of ctx.request to the options object here?

@migueloller
Copy link

migueloller commented Sep 21, 2016

@HriBB, that's correct. 😄

@HriBB
Copy link
Contributor

HriBB commented Sep 21, 2016

Here's the PR. This is a breaking change, and we need to mention it in the changelog. @helfer let me know how to proceed.

@leebenson
Copy link

I'm currently orchestrating like this:

router.post('/graphql',
  (context, next) => apolloKoa({
    schema,
    context,
  })(context, next),
);

This gives the 'full' context to the third parameter in my GraphQL queries, and makes context.state available (or, in fact,context.*)

Is there anything wrong with this approach? This pattern of orchestrating middleware in Koa2 is pretty common, when that same middleware needs access to ctx.state or ctx.request.

@DxCx
Copy link
Contributor

DxCx commented Jan 24, 2017

Im not a koa expert but it looks like a decent solution..

@DxCx DxCx closed this as completed Jan 24, 2017
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
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

7 participants