Flux over the Worker
elierotenberg opened this issue · comments
Please blame @vjeux for me promoting my work again!
To implement Flux over the Wire I rearranged the Flux abstraction slightly to make it more symmetrical. Basically, Flux has two sides, the single source of truth and the client components. The single source of truth observes actions and emits updates. The client components observe updates and emit actions. Emitting (action or updates) is fire & forget, the communication between the SSoT and the components is asynchronous by design. This allows to use the same abstraction for either local, traditional Flux, and for flux over the wire, which is basically having your single source of truth residing on your datacenter and your clients residing in your visitors browsers. Updates & actions are sent via Websockets (or polyfill), and stores are exposed as HTTP GET endpoints for performance and caching. This all works pretty well in practice for doing stuff like multi-user chat or magically auto-updating newsfeed.
However, this abstraction can basically sit on top of any asynchronous communication mechanism. One of the most promising is using it to communicate with a Webworker via postMessage. This would enable the state of the app to live in the webworker, and, more importantly, to have the action handlers run in this worker. Assuming we can efficiently transfer immutable objects back and forth between the window and the worker, then one can defer expensive business logic calculations off the main thread. While it would be very overkill for the typical TodoMVC demo, I think this could make sense for things like sorting huge arrays or calculating layout of stuff like that.
What do you think?
cc @jingc, @josephsavona
Assuming we can efficiently transfer immutable objects back and forth between the window and the worker
That would be really nice!
+1
I am experimenting with the idea of adapter.
var worker = workerAdapter({
path:"./dist/BL-Layer.min.js",
loadInsideWorker: true
})if loadInsideWorker is false then adapter will not load script inside worker thread, but it will load script inside main UI thread. So you can switch your mode at any time. when we load BL Layer inside main UI thread then communication can be done using simple pubsub event bus. we do not need postMessage API.
While development, we can keep loadInsideWorker: true and for production environment (If we face performance issues) then we can have loadInsideWorker: false
That sounds like a great idea @nsisodiya! The idea of the adapter seems to suit well as we have to be sure that the browser supports workers before trying to send stuff there (very important for prod as you said).
This remembered me of the SharedArrayBuffer proposal which could then speed things up (even though i'm not into how well browser implementors are accepting this idea). I also don't know what are the semantics or limitations of it but i imagine that readers-and-writers + notifications would fit pretty well to the architecture.
Anyway, just throwing another idea here 
What do you think?
@cirocosta - I have made a writeup on Adapter API or say it "Bridge API" - https://github.com/nsisodiya/flux-inside-web-workers/wiki/Communication-Bridge-between-UI-Layer-and-BL-Layer , current master has partial implementatation.