search

reactive-python / reactpy

It's React, but in Python
https://reactpy.dev
MIT License
7.9k stars 318 forks source link

Use Socket.io instead of Websockets #775

Open Archmonger opened 2 years ago

Archmonger commented 2 years ago

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

rmorshea commented 2 years ago

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

Archmonger commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Archmonger commented 1 year ago

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 commented 1 year ago

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