Just a follow up on this one: The websocket disconnects are not necessarily due to errors in the connections. It is of course possible that a connection is terminated due to loss of network connection or a node crashing due to out-of-memory conditions, but the typical scenario is that a connection is terminated due to node scaling activity in the cloud solution. This is an artifact of the dynamic nature of cloud based solutions and makes it possible for the system to load balance activity across nodes. An example is a case where a node is running an app that is quite large and that consumes a lot of computation cache memory. Another app is on the same node and competing for the same resources. The system can in such cases choose to move an app from one node to another, preferably one with more available memory. There are mechanisms in place that allows session to be transferred between nodes, and if you're working in the Qlik Sense client, then you hardly notice that this takes place. You might get a message saying that your are reconnecting, but once that has completed you can continue working as if nothing happened.
This mechanism does complicate things when you are working through the APIs though, because your websocket will be closed and a new one needs to be opened. But if the session has been moved to a different node, then you will get a "SESSION_ATTACHED" message when connecting to the app, and all your selections and everything will still be in place. So it's not correct to assume that the app session has been destroyed. It could very well have been moved to a different node.
However, the big problem from an API point of view is that there is state associated with the connection, not just the session. In particular, when you call and endpoint you need to identify the object for which you are performing an operation by using it's handle. This handle is part of the connection state; you get it for instance when you call "App.GetGenericObject". So when you reconnect, even to an existing session, you need to get new handles for all objects you are working with.
Another case where sessions get moved to different nodes is when a new engine version is being deployed across the system. The system will then empty engine for session before shutting them down and deploying the new version. Again, you typically don't notice this when working in the client, because all you get is a short "reconnecting" message, but it's up to the client to decide how to handle such reconnects. For the web client, there's always the "trivial" fallback solution to just refresh the page. That might not be so simple in your API based solution, but that all depends on what you're doing through the APIs.
