You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ReactPy-Django currently uses websockets as the primary messaging method for rendering.
This can be problematic because cloud providers (such as Azure or GCP) do not keep web workers running persistently. They are run on demand and will "randomly" restart after a certain idle timeout period, which leads to a bad ReactPy experience.
Proposed Actions
Idea 1: Restore Sessions
Add a configuration value, perhaps called REACTPY_RESTORE_SESSIONS that will enable ReactPy to serialize and re-use the user's current layout. These layouts should be directly tied to a Django session object (scope["session"]). Layouts should be stored in the database beforeany layout update is sent to the client. The layout will most likely need to be serialized via dill.
This proposed method does have flaws, the biggest of which being that any use_effect hooks will be terminated and restarted every time the client disconnects, resulting in some jerkiness, and the user application will be non-interactive during the re-connection process.
Idea 2: Heartbeat
Perhaps an alternative is creating a heartbeat message to prevent cloud workers from timing out (ref)?
The text was updated successfully, but these errors were encountered:
Current Situation
ReactPy-Django currently uses websockets as the primary messaging method for rendering.
This can be problematic because cloud providers (such as
Azure
orGCP
) do not keep web workers running persistently. They are run on demand and will "randomly" restart after a certain idle timeout period, which leads to a bad ReactPy experience.Proposed Actions
Idea 1: Restore Sessions
Add a configuration value, perhaps called
REACTPY_RESTORE_SESSIONS
that will enable ReactPy to serialize and re-use the user's current layout. These layouts should be directly tied to a Django session object (scope["session"]
). Layouts should be stored in the database before any layout update is sent to the client. The layout will most likely need to be serialized viadill
.This proposed method does have flaws, the biggest of which being that any
use_effect
hooks will be terminated and restarted every time the client disconnects, resulting in some jerkiness, and the user application will be non-interactive during the re-connection process.Idea 2: Heartbeat
Perhaps an alternative is creating a heartbeat message to prevent cloud workers from timing out (ref)?
The text was updated successfully, but these errors were encountered: