more context on our setup

apollo-server-express

is used as a middleware on the express app thanks to that, I can intercept the requests via middlewares and can make use of the node sdk if they go through plain http requests

understood.

so that's all fine there, but for the graphql subscription server, it's separate

entirely outside the express app so I can't ride on express middlewares and in turn can't make use of supertokens' provided middlewares

thus my question of is there a way to get the session manually, but I can't get the

res

object which the sdk needs 🤷‍♂️

So there must be a way that the socket connection is initiated right? Some HTTP request that starts the socket connection?

technically, yes there should be one

and that would go through your express server?

no and I think that's the problem, the only way we can interface with that, to my knowledge based on what I've understood in the docs of

subscriptions-transport-ws

, is via the

onConnect

hmmmm

so the

onConnect

is called as a result of a http request?

that I'm not quite sure how to verify 🤔

but it must be, right?

yea.. it must be haha

what's the structure of the context object?

it's pretty long, tried to trace the docs on what it uses but here:

socket

- the WebSocket object from the

ws

lib

and a

request

object of type

IncomingMessage

from the

http

lib 🤔

or wait, did you mean the

context

object on line 97?

yes

oh, no, that's a custom typescript interface for the app's consumption

I created that one, graphql resolvers have a concept of

context

on every request

hmm

you are returning the context, which means the

onConnect

functions "understands" the type you have made? So my question here is, what is the return type of the

onConnect

function?

the return type doesn't really matter, what gets returned by this

onConnect

function becomes the graphql context object of the graphql subscription resolver

it could be anything, and in this case , it should be this type, but of course I don't want to supply

req

and

res

objects when working with graphql subscriptions, thus the

Omit<T>

ok. give me somtime.. i'll have to read more about this.

then again, these types are unreliable in this scenario, as I'm not exactly receiving an express

req

object

since the subscription server is entirely separate

So another question: How is this server subscribed to in the first place?