On my migration to 3.0, I’ve noticed that we call ...

# apollo-kotlin

[Stylianos Gakis]

On my migration to 3.0, I’ve noticed that we call subscriptionManager here and there, always to call .reconnect() on it.

There is no mention in the migration files about this class. I am wondering if there’s some specific thing I can do to imitate whatever we were doing before, or if somehow this wouldn’t be necessary anymore due to the internals being changed somehow.

I’m trying to see when and why we call this so far (code that predates me) and it seems to be around places where we logout of the app, when we fetch a new token for our backend etc.

And I guess in general the question is how come that class completely was wiped from the internals, was it replaced with something? If not, how is that handled now in 3.0?

[mbonnin]

The code for subscription manager has been widely changed to be immutable. I was hoping that SubscriptionManager wouldn't be required but maybe I'm wrong.

[mbonnin]

Especially, when the user logs out, I think it'd make sense to create a new ApolloClient. i.e bind the ApolloClient scope to the user scope.

[Stylianos Gakis]

That’s the thing, I am not saying that I am looking for it exactly, it’s just that we were using it and I wanted to see if I am missing something that I should migrate to.
Thing is I don’t know if these reconnects() missing would break something because I am still in the migration phase where it’s not building yet, so can’t quite test it practically yet.

[Stylianos Gakis]

Creating a new client sounds interesting yeah, right now we do provide a single one globally through Koin. I would have to look into how to scope it in a way that makes sense for us. I will try that out if I see that things aren’t working as intended.

[mbonnin]

I see what you mean. I can see how a new user would require a new WebSocket. Whether we need an explicit reconnect() is another question and I'd rather have users rebuild their ApolloClient, even maybe keeping the OkHttp threadpool if required

[mbonnin]

ApolloClient isn't that heavy of a class and having a user-scoped ApolloClient would also ensure no cache leaks between users and other stuff like this

[mbonnin]

But maybe there's a use case I'm missing somewhere. We could add a webSocketNetworkTransport.reconnect() if it's the case

[Stylianos Gakis]

We haven’t quite got the codebase made in a way that things are scoped like that right now unfortunately, which is why I assume we also just using reconnect in such cases. We’re just providing literally everything with koin’s single 😬
This may mean that we’d need to tackle that part in this migration as well. Maybe it’s high time we did that though 😄
Have you had anyone else come with questions about this use case? I wonder if this is only a (potential) problem for us since we have all these things globally provided everywhere.

[mbonnin]

This hasn't come up yet but I'd be surprised you're the only one. WebSocket management is not easy and I'm hoping we can somewhat clarify best practices with 3.0

[Stylianos Gakis]

Yeah that’s true. I’m practically completely clueless about this topic, so I don’t think I have any good input, but if you do have some ideas around this maybe it’d be worth for them to exist in the documentation in some way

[mbonnin]

Indeed, very good point.

[Stylianos Gakis]

But since you’re bringing this up, what is it that makes handling WebSockets hard? Is the problem if there are existing subscriptions while we’re logging out for example? What if there are none and the get created only later after logging in again?
Is it that a connection gets established on ApolloClient creation and this may mean that if throughout its lifecycle we want to change stuff like the headers passed etc. it’s too late since that one is already running?

I am shooting random thoughts basically now since as I said before I know nothing about the topic, but maybe you can give me a hint about what I might have to worry about in this migration?

[mbonnin]

Yea, all that kind of stuff. It's very stateful.

[mbonnin]

There's also the question of handling internet disconnections on mobile and/or shutting down the WebSocket when the app is not in the foreground (to save some battery)

[Stylianos Gakis]

Hmm yeah interesting. Sounds like we’re gonna have problems then in general. I will try my best to come back to this discussion when we eventually start testing this. I may have more ideas about it then. Will just remove them for now and continue migrating 😄

[wasyl]

Generally, you could probably also lift the "reconnect" method to a singleton that also holds/recreates the Apollo client. Just to avoid reshuffling the scopes to have Apollo scope same as the user scope

[Stylianos Gakis]

A simple class that holds the apolloClient and exposes a reconnect() function which recreates the apolloClient it exposes right? Yeah might be an easier step to do this 👀

[wasyl]

Yeah exactly, lift the reconnect to some place you control 🙂

[bod]

Hello, World! Just to let you know that v3.3.0 has just been released and it contains closeConnection, an equivalent of the 2.x reconnect. More info here 🙂

(thanks @mbonnin for finding that thread!)

[Stylianos Gakis]

You folks never fail to amaze me with your proactive approach of understanding and solving our problems. Thanks a lot, you’re awesome!

[mbonnin]

THANK YOU for all the feedback 😊!