reactpy icon indicating copy to clipboard operation
reactpy copied to clipboard

Use Socket.io instead of Websockets

Open Archmonger opened this issue 3 years ago • 6 comments
trafficstars

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

  • #581
  • #525

Archmonger avatar Jun 25 '22 04:06 Archmonger

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

rmorshea avatar Jul 01 '22 06:07 rmorshea

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 avatar Jul 01 '22 06:07 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.

Archmonger avatar Apr 29 '23 05:04 Archmonger

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 avatar Apr 30 '23 03:04 rmorshea

I need to learn more about YJS, but it's possible that we should take the same approach with https://github.com/reactive-python/reactpy/issues/826

rmorshea avatar Apr 30 '23 03:04 rmorshea

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.

Archmonger avatar Apr 30 '23 05:04 Archmonger

Note: we will probably end up using the SocketIO ASGI app once we have our middleware up and running.

Archmonger avatar Aug 10 '23 06:08 Archmonger