Rejoin behavior and promises

[akeating]

Thanks for putting this together. I notice absinthe-phoenix-js relies on the phoenix Socket lib, layering on subscriptions. The main methods return promises (connect, subscribe, unsubscribe). These promises are resolved or rejected based on callback handlers which may fire multiple times. For example, socket.onOpen can fire more than once, re-executing an attempt to create a channel. The underlying behavior causing this is retry/rejoin. Once opened, Socket will attempt to reconnect and rejoin. If the server connection is terminated, Socket will retry/rejoin for you. onClose, onOpen and friends can fire more than once. I would argue that the use of promises are not really a good fit when used on this manner. That said, promises are definitely useful and they could be implemented without directly relying on the callbacks. This lib could also attempt to resubscribe on rejoin. Wondering whether these are known issues and if there is already an effort underway to solve them?

[bruce]

These are known issues, and I agree with you on the promises. Seemed like such a good idea at the time.

There is probably not going to be a lot of headway made on solving them here until ElixirConf, due to time constraints for Ben and I; most people seem to be using phoenix-websocket-apollo in practice (which is a completely different implementation and likely handles this) and I know @tlvenn is actively working on putting together a Relay-supporting package.

We really do need a vanilla package like this, however, and I would welcome any assistance to make this more solid.

[tlvenn]

The relay solution we have use this project underneath as I believe it would be better to factor the protocol on how a given channel is being used between absinthe server/client is one place.

I agree with the sentiment regarding promises in this use case and we should aim to return observables just the same way as subscriptions-transport-ws is now dealing with this.

It's probably something we can work on and contribute back @bruce. Let me check with the team and report back.

[bruce]

@tlvenn Thank you, that would be very helpful!

[akeating]

I too have been contemplating a fundamental refactor that aligns with subscriptions-transport-ws. That api looks very useful. Trouble is, I am tempted to refactor the phoenix socket lib to surface parts of it, such as reconnecting, reconnected, et al. I believe this would result in a better implementation, but at the cost of taking on and maintaining compatibility with phoenix. It might be possible to carefully wrap the phoenix lib and at the cost of complexity further up the stack.

[bruce]

@akeating @tlvenn's team has also been looking at a pretty fundamental refactor here––may want to review what he's doing as well. @tlvenn, when do you think we can take a peek?

[tlvenn]

@bruce Hopefully tomorrow, I will keep you posted.