-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Federation: subscription protocol, websocket and authentication #268
Comments
Good spot. I think there are two cases:
Would you like to add an option for keeping one connection on each front? The problem would be scaling such a deployment as it significantly increase memory consumption of the gateway. I'm not opposed on adding an option to support this second mode of operation. |
I also thought to this solution but I removed it before posting the issue because: If the server is aware of the gateway this kinda breaks the 'pug-and-play' aspect of the federation, I mean that the service will need some custom logic in the resolvers to handle message coming from the gateway. It also doesn't work well with the current design of graphql subscriptions (inspired by apollo implementation): in the current implementation, authentication logic is usually handled by headers or in the |
Hum I think I understand better your point 1 now. We could extend the |
+1 |
Closed by #271 |
I'm experimenting with federation and subscriptions and I noticed a flaw in the current implementation.
Problem
When the gateway starts and
services.wsUrl
is defined, the gateway will open a ws connection with each services and send theconnection_init
payload.Once a client creates a websocket connection and sends the
connection_init
payload, the gateway will instantiate aSubscriptionConnection
and uses the gateway'ssubscription.onConnect
handler. Now, if the Client wants to start a subscription with thegql_start
payload (defined by a federated service), the gateway will use the existing connection of the federated service and forward thegql_start
payload and then it will forward any message coming from this subscription to the original client. This means that the federated service uses the sameSubscriptionConnection
for every gateway clients.The issue here is that the service that defined this subscription and holds the logic/validation/permissions etc. didn't received the
connection_init
payload. Thus services have no way to authenticate and authorize messages coming from the gateway (the issue is the same if we use websocket headers as the connection between service and gateway was establish before any client request).Solution ?
I think that the solution would be to establish a connection from gateway to service per client:
The gateway will not open websocket connections at startup, but only if needed. It can then forward the
connection_init
payload, initially received during theclient <-> gateway
handshake, to the related service. The federated service will create aSubscriptionConnection
that is properly isolated per user.This solution will create more connections between gateway and services but it should allow services to properly handle authentication/authorization and isolation without modifying the subscription protocol.
Before trying any implementation I wanted to share this issue because I'm not sure if it's a good idea to store the
connection_init
payload in-memory to be able to establish new connections but I currently don't see any other way that wouldn't require modification on the service side or on the subscription protocol. This would also decrease the overall performance of the gateway as it should handle more connections.The text was updated successfully, but these errors were encountered: