Apollo-server: "this" context or request data is unavailable from apolloKoa()

[saeho]

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]

Koa 2 is supported I guess.

So headers contains in ctx object.
Related issue
https://github.com/apollostack/apollo-server/issues/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]

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

cc @HriBB

[saeho]

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]

@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]

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]

@helfer
https://github.com/mikeifomin/apollo-server/commit/6584ac4ff369db09cc98c4c91b57a1c37e2892fd

[helfer]

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

[mikeifomin]

@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]

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

[helfer]

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

[migueloller]

@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]

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]

@HriBB, that's correct. 😄

[HriBB]

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]

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]

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