Question: Timeout and disconnect strategy about enigma.js

[peol]

Full reconnection is tricky business today, based on how Engine works (e.g. making sure existing APIs retrieved from enigma.js continue working etc.), we always imagined this being done outside of enigma.js but I definitely see the benefit of supporting seamless reconnection.

We do check if we're connected before trying to send messages (albeit a bit primitive): https://github.com/qlik-oss/enigma.js/blob/master/src/services/qix/rpc.js#L152

The trickiest thing is to reproduce the state in Engine, so one reconnection strategy could be that you have a proxy in front of Engine that would always keep the session (socket) to Engine open, and if the Client disconnects it'll keep it for a while and if the Client comes back the Client state should be valid enough to continue working against said Engine with a pretty small effort. This of course, only works as long as that proxy has a connection against the Engine. If that drops, the session as a whole wouldn't be able to reconnect.

[mindspank]

Yeah, I'm just trying to wrap my head around how to approach it in the best way for a project.
How about websocket events, I can see they are emited in the code but they are not mentioned in the docs as far as I can see.

[goldbergjeffrey]

noob question, how does one force a websocket disconnection with enigma? Like I want to disconnect and then connect to a new app?

[peol]

@goldbergjeffrey The best-practice here would be to not define appId in your configuration to make sure your qix.global and any opened apps are separate websockets. You can then do global.openDoc(appId) to fetch an app, and app.session.close() to disconnect. If you meant how to re-use websockets for new apps, that's not possible (not supported by QIX Engine).

[goldbergjeffrey]

@peol thank you for the advice. The way I'm writing my config I send in an appid, but it reads like that is not a good idea I'm better off terminating the web socket and creating a new one and doing open doc so that's what I'll do.

[peol]

@goldbergjeffrey Yeah, I've written down that we should clarify "best-practices" for these use-cases.

Basically, if you will only work towards one app in your session, define appId in your configuration, otherwise you're better off not defining it and use global.openDoc.

[peol]

We are currently looking into this in an internal issue, you'll see public-facing issues tracking a similar functionality soon.