Are there any plans to add the ability to have web workers scripts?
I imagine it something like server connect actions except they can be run separately as web workers for heavy lifting background tasks.
Yes that is exactly what we plan to do. Add server connect like functionality client side in the form of web workers.
Those will be just flows but not page bound that execute in workers.
Useful for mobile apps, desktop apps and web apps without server side.
4 Likes
That sounds great! Any ETA on when web workers will be released?
It will actually also integrate service workers and their events, so it will be the perfect foundation for any PWA
No ETA yet however but we do hope to get to it in the next month or two.
3 Likes
Is something like this already possible on the server side or is that planned with this too?
Hey @George, just wanted to revive this request. I’m running into UI issues in my Capacitor app because the main thread is getting blocked by App Flow processing.
It would be great to have app flows run in web workers or, even better, as shared workers. With a shared worker I’m hoping I could maintain a single background task that processes data from an api. Even if the user navigates from one page to another page, the Shared Worker could persist and continue running on a schedule.
1 Like
Global App Flows should be easy to be run in a web workers, this was also our initial design. Will check with @patrick how for are we on this.
3 Likes
How will this potentially work @George - soon i’ll be looking at Bull Q’s, but perhaps we could build our own simplified version if we can extent App Flows into workers?
Will App Flows running in Web Workers help with this issue?
On top of App Flows running in web workers, I stumbled across this adapter for running Pouch in Web Workers as well.
1 Like
Hi @george, any chance this is in the pipeline? I’m starting to run into limitations without this feature.
2 Likes
Could you give more use cases of what you want to execute in an App Flow possibly running in a web worker? Is it for web or mobile usage?
Because web workers are limited of what they can execute.
My use case is for mobile/desktop Capacitor projects. I have an action scheduler that triggers an App Flow to check for new data from third-party APIs. It then processes the data and inserts into SQLite.
Long term, I want this processing to continue even if the user navigates to another page, so if something is processing and the user changes pages the processing will continue.
I believe this means using Shared Workers, instead of Web Workers.
https://javascript.plainenglish.io/introduction-to-shared-workers-533d9abe9de3
We will investigate more, but for the mobile capacitor environment, probably the background runner is the best solution:
The challenge with Capacitor plugins is their availability in Electron apps. Or at least the documentation doesn’t mention Electron.
Looks like there are also limits on run time. The initial processing of data that I’m attempting to do runs for a few minutes.
yes but you should see it as a scheduler - you just schedule the run of some App Flows - that just run quickly and fetch needed data. Like check for new data each 15 minutes or so,
Fetching data or push notifications are the primary usage for background tasks
1 Like
Yeah, I’ll probably have to figure out how to work around those limitations to get the initial data (e.g. last 30 days of emails).
bumping this.
@George I know you never answer on timelines and fully understand why - but is this at all likely as a very near-term feature?
I’m needing to hand some stuff off to a background task to speed up the user-experience. I’ll look for a different way of doing this if this isn’t likely anytime soon.
Thanks!
1 Like