Use Socket.io instead of Websockets

[Archmonger]

Current Situation

Currently, IDOM does not fallback to keep-alive HTTP persistent connections in the event that Websockets are not supported.

Proposed Actions

Utilize replace Websocket connections with the Socket.io API, which fills in this gap.

We will need to use python-socketio for compatibility, likely the same way they do with Tornado.

Related issues

• Give Feedback About Connection State #581
• Improve Reconnecting WS Configurability #525

[rmorshea]

Are there any modern browsers that don't support websockets?

[Archmonger]

No - But the issue isn't due to browser support. Reverse proxies are known to sometimes be unstable with Websockets under certain configurations. This issue is compounded when using multiple reverse proxies (ex. Nginx + CloudFlare).

Over in the Organizr group we see these problems fairly frequently. Most of the time it's fixable through configuration, but a lot of web dev communities have moved to using either Signalr or Socket.io just to avoid the constant user support questions.

[Archmonger]

Socket.io will result in us only supporting requiring web frameworks that support long-polling HTTP.

But at that point, we may as well axe our websocket-based design and only use long polling HTTP. If we did, it would resolve our file upload problems.

@rmorshea What's your opinion on switching the framework to rely on HTTP long polling? I can draft a proof of concept if you'd like.

[rmorshea]

I think this should be implemented as an independent backend first. Doing so has two benefits:

1. It will likely expose areas for improvement in how we expect backends to be defined.
2. It won't have to wait for a 2.0 release.

I'm particularly interested in 1 since, while not practical at the moment, a socket-io backend ought to be able to re-use code from the existing backend definitions since it will only need to provide a new client and _reactpy/stream route. I can imagine a world in which it's possible to swap out the "transport" for a backend - e.g. perhaps a transport could just be an ASGI/WSGI server that's mounted at the appropriate route.

[rmorshea]

I need to learn more about YJS, but it's possible that we should take the same approach with #826

[Archmonger]

After looking at python-socketio, the file serialization situation might already be a solved issue?

The javascript socketio supports file transfers, but I have no idea how this interfaces with python-socketio.

EDIT: Looks like it doesn't natively support file uploads. If we can figure out a way to use each framework's HTTP internals to handle file uploads, that is probably best.