Redux: Moving business logic into a Web Worker

[jscriptcoder]

Hi there,

Allow me to show an example of a redux app, where I moved the whole business logic layer into a Web Worker, leaving the UI layer in the main thread. Redux is great to make such task an easy one.

https://github.com/jscriptcoder/redux-worker

Just a proof of concept, but I find the idea interesting to look into. My only concern is the whole passing messages back and forth, serializing, deserializing. But it's proven to perform quite well when adding a couple of thousands tiles, compared to the implementation without using a Web Worker.

Thanks,
Fran

[markerikson]

Yeah, there's a couple other similar variations on that concept : https://github.com/markerikson/redux-ecosystem-links/search?utf8=%E2%9C%93&q=worker

Out of curiosity, what prompted you to try that? Were you seeing any specific performance issues, or was this more of a "would this work?" kind of thing?

[jscriptcoder]

Oh, great... I'm very interested in exploring this concept and it's great to see other examples.

The reason why I'm looking into this idea is because the application I'm currently working on is having lots of performance issues. There is a huge amount of data coming from the backend, via WebSocket, with hundreds of updates per second, plus a heavy interaction with the application making it quite slow and jerky. I'm using Angular 1.x (I know, bad idea for this kind of apps)... Redux is definitely going to improve the performance, but the huge amount of calculations happening is making me explore the Web Worker field, trying to move all that logic there.

Fran

[markerikson]

What sort of performance issues are you running into? Have you done any profiling? Are the current bottlenecks happening at the reducer level, in UI rendering, or somewhere else? What sort of data are you dealing with? What's happening with each of these updates? Can they be batched in some way?

Here's a couple other resources you may be interested in:

• Links to several articles on Redux performance: https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#redux-performance
• A rewrite of React Redux's connect function that uses memoized selectors to improve performance. I realize you're using Angular and not React, but there may be some of the concepts you could port over: https://github.com/reactjs/react-redux/pull/416

[jscriptcoder]

I have no issues with Redux, I mean, the performance issue is Angular and its dirty checking. The idea is to get rid of it and use simply Redux architecture or combine it with Angular (also something I'm currently looking into).

Thanks a lot for those links.

Fran

[deowk]

This is also something I want to start looking into, we recently deployed a react + redux app to a variety of Smart TV's where performance was a serious issue - dispatching any action while animations etc are taking place causes major frame rate issues - these TV's are not very powerful (even when compared to mobile devices) - handing off the actions & api calls to webWorkers was and still is something we are considering in order for the UI to run on it's own thread without interruptions

[tracker1]

@deowk Just be careful if you're serializing large amounts of state, that can wind up costing more than the worker saves... It may be worth doing a call to a worker semi-rpc, that can handle async operations... maybe mirroring the dispatch calls on both sides...

[markerikson]

@deowk: I'm kinda curious on that myself. Are you saying that _dispatching to a reducer_ was a bottleneck? Or that _UI updating_ was the bottleneck?

[jscriptcoder]

@tracker1 The state doesn't have to leave the Worker. The UI layer would only contain dumb components, sending event actions to the Worker. The Worker would send back to the UI only the change for the component/widget to update its view.

[deowk]

@tracker1 @markerikson This particular app has a very rich UI with loads of animations and transitions + images, we have already invested heavily on optimizing the UI such as only rendering elements that are on screen, using the transform property to prevent the layout from getting repainted and taking advantage of GPU acceleration. Just to put it into perspective, the current version of the app runs at 60fps on any Desktop Machine / Browser. The TV however is another story - sometimes animations / page transitions take place whilst actions are getting dispatched (we have tried to limit this to a minimum) - ANY action getting fired while transitions are taking place seems to block the thread and frames get dropped as a result - this is indeed an extreme case and probably not applicable to most web apps but due to the scarce resources on these TV's it is a concern for us.

[markerikson]

@deowk : Definitely sounds like you've put in quite a bit of time on this, but I'd still be interested in hearing more about where exactly the bottleneck is for you. Unless you're running _very_ complex code in your reducer functions, the actual dispatch process _should_ be short and simple: a few function calls, a bit of object creation, and that's it. Even on a low-powered device, that seems unlikely to be causing a strain. Not saying that there's no way you could be having problems, just trying to better understand what's actually causing issues for you.

[deowk]

@markerikson Yeah to be fair redux is defo not the issue here, we are not doing anything crazy complicated in the reducers or actions, the rich UI coupled with animation is the bottleneck (the UI is just consuming too much resources), but getting the UI to run on it's own thread is a more complicated affair since webworkers don't have access to the DOM, so running everything else in it's own thread is kind of a backwards way of solving it...but at the moment it's path of least resistance....;)

[timdorr]

I think this might be best left to an external library. One that can broker the communication of actions and state changes between the primary JS environment and the worker.

The neat thing is actions are pretty easy to communicate, since they are normally serializable objects that you can easily ship over the IPC wire. Receiving state changes might involve the concept of subscription selectors so that you keep the state transfer to a minimum. But you can use something like RxJS for that or get fancy and do something like MobX's automatic observable subscriptions.

[dmitrijs-balcers]

@deowk did you try to run redux store on webWorker? Did it help? Looks like I have run in similar issue.