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?

via the

http

Is there some

connect()

function to call on the frontend?

idk if this helps but

createServer

is from the

http

lib, the

app

variable is the express app inside the

initApolloGraphqlServer

is where we register

apollo-server-express

as a middleware which is all good for http requests AND also where the subscription server is created separately

no i mean to ask from the client's point of view, how do they connect to this web socket server? Is there a way to pass some info on initial connect which can be verified in the

onConnect

function? I ask because you can implement the following

send an http request containing the graphql subscription document, some magic happens, and the ws is established xD

- before connecting to the graphql subscription server, the frontend can query some endpoint in your express app which uses normal session verification. - in that endpoint, if a session exists, you return the

sessionHandle

of the session to the client. Else some error - If the client gets the session handle, it passes that to the request to the

onConnect

function. - In the

onConnect

function, if the req doesn't have a

sessionHandle

, then

return false

(which will cause a disconnection). Else query the supertokens core to check if the

sessionHandle

exists. If it doesn't

return false

, else return the context object to establish the connection.

wait, let me check if I follow

so I get the session handle via

SessionObject.getHandle()

?

yup

then return that value to the frontend

yup

then the frontend client passes that value to the backend

to the graphql server

check in

onConnect

via supertokens-node.getSessionData(), yes?

I mean, it's the only one that accepts session handle from what I can see in the docs xD

if that doesn't throw an error, then there's a session

yup.

exactly

kind of vague to me but, aren't these sessions not deleted in the tables?

they are if the session is revoked / expires.

I see, this should work, a bit of added latency due to this extra call tho

referring to the getting of the session handle

add it on the jwt payload maybe so it's easily accessible? but that value refreshes when the rotation of access tokens happen, right? 🤔

> add it on the jwt payload maybe so it's easily accessible? Yea.. you can! But you will have to do this post session creation. But honestly, this extra hop doesn't make much of a diff unless you have a HUGE HUGE userbase.. cause it happens only once on connect.

true haha