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
Right now Mesop uses Server-sent Events (SSEs) which have been good, as they are widely supported and relatively straightforward implementation-wise, however there's some limitations with more advanced use cases.
There's a key problem here which is that our core rendering loop in handling long user interactions (via generator) assumes that you can generate tree diffs from the previous tree in your context (i.e. SSE request).
Example use case
With concurrent updates, you can run into strange bugs like the following:
SSE Request 1 (long) - after 4 seconds, it tries to update the tree by adding component A
SSE request 2 (short) - after 1 second, it tries to update the tree by adding component A
In this case you will end up erroneously adding component A twice because the first SSE request (which takes longer) still sent a component tree diff to add component A even though it was added by another request (that completed sooner). I ran into this issue in my personal app and it's not very intuitive to debug and points to a core issue which is that concurrent updates across multiple stateless server instances is bound to be problematic. Instead, I think having a model where there's multiple concurrent updates getting funneled into the same stateful server instance is more robust.
Implementation plan
I have a PR #1027 which prototypes support but it's failing many of the test cases. Once I take a closer look and can get most/if not all of them passing, I think we can add a new mode to Mesop, e.g. MESOP_WEB_SOCKETS_ENABLED. I think this will always be an opt-in because our current setup (SSE) is quite robust and works for most use cases.
The text was updated successfully, but these errors were encountered:
Context
Right now Mesop uses Server-sent Events (SSEs) which have been good, as they are widely supported and relatively straightforward implementation-wise, however there's some limitations with more advanced use cases.
Motivation
There's a key problem here which is that our core rendering loop in handling long user interactions (via generator) assumes that you can generate tree diffs from the previous tree in your context (i.e. SSE request).
Example use case
With concurrent updates, you can run into strange bugs like the following:
In this case you will end up erroneously adding component A twice because the first SSE request (which takes longer) still sent a component tree diff to add component A even though it was added by another request (that completed sooner). I ran into this issue in my personal app and it's not very intuitive to debug and points to a core issue which is that concurrent updates across multiple stateless server instances is bound to be problematic. Instead, I think having a model where there's multiple concurrent updates getting funneled into the same stateful server instance is more robust.
Implementation plan
I have a PR #1027 which prototypes support but it's failing many of the test cases. Once I take a closer look and can get most/if not all of them passing, I think we can add a new mode to Mesop, e.g.
MESOP_WEB_SOCKETS_ENABLED
. I think this will always be an opt-in because our current setup (SSE) is quite robust and works for most use cases.The text was updated successfully, but these errors were encountered: