Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve cloud hosting stability #271

Open
Archmonger opened this issue Dec 7, 2024 · 0 comments
Open

Improve cloud hosting stability #271

Archmonger opened this issue Dec 7, 2024 · 0 comments

Comments

@Archmonger
Copy link
Contributor

Archmonger commented Dec 7, 2024

Current Situation

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 before any 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)?

@Archmonger Archmonger changed the title Develop cloud compatible state restoration Improve cloud hosting stability Dec 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant