Is it possible to add middleware à la express?

[nhuesmann]

In my current prisma2/nexus app, I'm using graphql-yoga. It exposes the underlying express server, on which I can call .use to add middlewares. Important middlwares to me are:

• express-session
• graphql-middleware-sentry

The most important thing to me is being able to continue using express-session with Redis, as that's a core feature in my app and makes session handling a breeze. Is there any way to achieve this functionality currently with graphql-santa? I know it's built using apollo-server-express, I just wasn't sure if you'd exposed that functionality.

[jasonkuhrt]

It’s not exposed currently. I also have uncertainty that we’ll stick with express as per #231. TBD

Exposing would be trivial but even as an escape hatch I’m concerned about apps depending on something we might break hard.

Maybe we could make the server component swappable... different plugins.

[nhuesmann]

@jasonkuhrt ah yes, I'd seen that issue- If a large perf increase can be had, I'm all for it, even if it means I can't get parity with what I currently have. Swappable server sounds interesting, I'd be interested to hear that fleshed out. If I had to choose between perf increase and being able to use express session, I'd probably lean toward perf. However if I can't include the express session middleware in my GQL/prisma/santa server, that likely means putting it in another server and adding latency. So there's a chance the perf gain from switching to fastify-gql might be offset by additional complexity/latency of putting my session handling somewhere else.

This is just my own situation- obviously you should design for what the majority of users want. If this doesn't end up being something a lot of people do, then I'd understand just not exposing the functionality. I'd be interested to see how other people are handling sessions when using GQL servers, just as an aside!

[jasonkuhrt]

Hey @nhuesmann check out #523

[nhuesmann]

@jasonkuhrt Hey, just checked out #523, need some time to digest. Would I be using server.middleware instead of server.custom? Also would it be replacing schema.addToContext, i.e. I would instead use a middleware that augments context?

[jasonkuhrt]

Would I be using server.middleware instead of server.custom

Correct.

But, of course, only to the extent the the Nexus API does what you need. server.custom will remain an escape hatch.

Also would it be replacing schema.addToContext, i.e. I would instead use a middleware that augments context?

Correct.

FYI related #524.

[nhuesmann]

Oh #524 is interesting, with having the context be importable from nexus. Is the example provided the actual plan? This one:

 import { context } from 'nexus-future'
 
 context.foo = 'bar'

[jasonkuhrt]

@nhuesmann tbd, up for discussion

[jasonkuhrt]

@nhuesmann fyi I migrated this from gh issues to gh discussions. I think it makes sense. Hope that's ok with you.

[nhuesmann]

@jasonkuhrt Absolutely, forgot about that feature but it makes sense as a discussion 👍🏼

[paniavula]

Hey @jasonkuhrt, how would I write a plugin similar to that of LogMutationTimePlugin in the link https://nexus.js.org/docs/api-plugins? I would like to access graphql args as well so I can write some common validation routines and few other functionality. This also helps me to use t.crud directly instead of t.field in most of the cases.

I checked the below and the nexus source code, but using graphql args doesn't seem to be obvious.
https://www.nexusjs.org/#/guides/writing-plugins?id=how-it-looks

[jasonkuhrt]

Hey @paniavula this looks like it could be a new discussion? Feel free to open one.

[paniavula]

never mind. I figured it out.

[jasonkuhrt]

Now that we expose express directly, I think we can close this discussion. Any objections @nhuesmann?

[nhuesmann]

Ah sorry for the delay—no objections, go right ahead!