search

ardatan / graphql-mesh

🕸️ GraphQL Mesh - The Graph of Everything - Federated architecture for any API service
https://the-guild.dev/graphql/mesh
MIT License
3.22k stars 332 forks source link

Recreate WebSocket client when `connectionParams` change during execution #6335

Open enisdenjo opened 7 months ago

enisdenjo commented 7 months ago

Related https://github.com/ardatan/graphql-mesh/issues/4305#issuecomment-1215000504, repro: https://github.com/enisdenjo/graphql-mesh-apollo-sample.

The actual problem why the repro is failing is because the WebSocket instance in Mesh is instantiated during initialisation providing the connectionParams, and then that client instance is used during execution. If this weren't so, each subscription would create a new WebSocket connection itself - which is not ideal.

Provide a way of re-creating the WebSocket instance when the connectionParams change.

ardatan commented 7 months ago

How do we decide that connectionParams is changed?

enisdenjo commented 7 months ago

We'd probably have to store it together with the instantiated WS instance. TBH, I haven't thought about it in detail - I just investigated.

petrepatrasc commented 2 months ago

Hey, we currently use connectionParams as our strategy to ensure that a user is authenticated when interacting with GraphQL subscriptions. Specifically, we pass a JWT token via connectionParams.token, which is then validated in the subsequent service for the GraphQL subscription.

This works well for the first request after starting Mesh and the parameters are proxied correctly, however the connectionParams are then cached for subsequent requests, meaning that Mesh as a whole inherits the session of the first user making the request. Our expectation was that this would behave more similarly to operationHeaders, where the values are passed dynamically.

As I understand from the discussion that @enisdenjo triggered above, this is not currently supported in Mesh, and the current behaviour is to keep the Websocket instance shared.

What would be the right approach then for this workflow? Should user authentication for websocket connections occur before reaching Mesh (i.e. in an API gateway?). Even so, there may be other parameters that need to be sent to the underlying services (i.e. multi-tenancy discriminators) which change per connection.

perzanko commented 3 days ago

@petrepatrasc We have encountered the same issue. How did you solve it?