Apollo-ios: WebSockets Subscription lifecycle

Created on 19 Dec 2019  路  2Comments  路  Source: apollographql/apollo-ios

At the point where my ApolloClient is created, I have yet to have authentication established. With HTTPNetworkTransport, this is fine, because I have the HTTPNetworkTransportPreflightDelegate which allows me to add the authentication headers at a later point. With WebSocketTransport that doesn't seem to be possible, although I erroneously assumed It would be via RequestCreator.

So my questions are:

  1. Am I wrong in comparing the lifecycle of WebSocketTransport with HTTPNetworkTransport?
  2. What would be the best approach for this situation? Only create an ApolloClient when the authentication has been established?
  3. Potentially make WebSocketTransport lazy, instead of eager?
apollo-websockets question

Most helpful comment

  1. Yeah the problem is that the web socket opens a connection on creation, and you can't change the "headers" of that connection once it's made (unless it disconnects and reconnects, but I don't think that's super-recommneded). Because opening a web socket is more of a one-shot deal in terms of being able to send authentication information, it's not super comparable to the HTTP client, since that sends the headers per request.

  2. Yeah, I would say waiting to create the client with a websocket until after you're authenticated is probably worth it at this point. Again, in theory you should be able to reset some headers after login, but that won't have effect on the websocket unless you disconnect and reconnect, and that may have other side effects I can't really predict.

  3. It seems ideal in the longer term to have the web transport connect more lazily, but I have a suspicion that this will open a significant can of worms in terms of constantly checking if the connection is open and then waiting to open it if needed. I'd love to see a PR on it though if you've got the time!

All 2 comments

  1. Yeah the problem is that the web socket opens a connection on creation, and you can't change the "headers" of that connection once it's made (unless it disconnects and reconnects, but I don't think that's super-recommneded). Because opening a web socket is more of a one-shot deal in terms of being able to send authentication information, it's not super comparable to the HTTP client, since that sends the headers per request.

  2. Yeah, I would say waiting to create the client with a websocket until after you're authenticated is probably worth it at this point. Again, in theory you should be able to reset some headers after login, but that won't have effect on the websocket unless you disconnect and reconnect, and that may have other side effects I can't really predict.

  3. It seems ideal in the longer term to have the web transport connect more lazily, but I have a suspicion that this will open a significant can of worms in terms of constantly checking if the connection is open and then waiting to open it if needed. I'd love to see a PR on it though if you've got the time!

Makes sense. I will close this issue since at least I have a way to move forward. Thanks! 馃殌

Was this page helpful?
0 / 5 - 0 ratings