Tell us about how you're pushing the limits of compute in the browser!

[zakhenry]

We're curious about what other applications are using observable-webworker to push browsers to their compute limits! I'll start:

observable-webworker was developed internally @cloudnc to handle a very intensive computation where we were taking gcode files, parsing them into toolpaths and simulating what cutting metal on a cnc milling machine would look like.

We could subdivide the problem into regions which enabled parallelism, but we needed good system for managing the streams of data going to and from the webworker pool, and so began observable-webworker.

We've since replaced the feature that was the genesis of observable-webworker, but in the interim now use it for large file hashing and svg thumbnail generation from a 3D mesh model (using Rust/WASM!).

[lincolnthree]

Hey @zakhenry !

This is a nice question to ask :) I am the owner/developer of www.topdecked.com, a site dedicated to Magic: the Gathering players and fans. Since we use a hybrid app deployment model, it's critical everything we do works in the browser (all major browsers).

Due to the deprecation of WebSQL, we've been starting to move to IndexedDB, which is not quite as performant for complex queries. To alleviate some of this slowdown, I've started using Web Workers for all database transactions/operations. This helps offload some of the "in-application" joining and filtering to background threads that don't block the (already complex) ui.

As you can see in the screenshot above, there are quite a few search options, so this processing can be fairly intensive with over 60,000 records stored in IndexedDB on mobile devices. So Web Workers are a crucial part of keeping the application performant.

I also have started to use them for doing complex calculations like graph operations to make associations for recommending ideas based on previous choices and actions, a bit of Machine Learning in the browser :)

One thing I think would be interesting is a utility to queue operations to send/receive uniquely identified/numbered messages to a single worker, so that it could be long-running, and shared between multiple Observable consumers, instead of spawning a new a new worker for each request.

This is of course doable already using a messageId parameter, but it would be fantastic if there were some syntactic sugar around this :)

[zakhenry]

Oh wow that is an awesome use-case, I hadn't considered that local db querying might be intensive.

Regarding the long running worker request, I'm wondering if the worker pool strategy would work well for this? You could restrict concurrency to 1 if you want to only have the one worker, but it seems like it would solve your scenario? This would have the nice advantage that if there is more load than the single worker in the pool can handle, you can bump up the concurrency with no further effort and everything else will continue to work as before, just faster.

Also you should be able to use the share() operator to multicast to multiple observable consumers.

If this doesn't fit the use case and I'm misunderstanding, please feel free to raise a feature request issue :)

[abarke]

We are investigating using a Service Worker as a shared data hub (across tabs and windows) that contains a single WebSocket client. The idea is that instead of establishing a WebSocket per window/tab, we just connect to the already running WebSocketSubject created using RxJs that sits in the Service Worker.

This way we have a single Service Worker service that handles requests/subscriptions to our backend while adding a caching layer and offloading the intensive data handling/deserialization/compression/caching to the Service Worker allowing each window/tab to consume only the data it requests/subscribes to and supplying cached results immediately.

The challenge in this architecture would maintaining backwards compatibility with browsers that do not support Service Workers, allowing the basic 1 WebSocket per window/tab.

I realize the interface is similar when using Web Workers, however does this library also support Service Workers?

[pascalvaccaro]

I am writing a drawing application that combines user-gesture analysis, digital music/sound design and image processing.
We are still in the early/POC phase where all drawing using <canvas /> is done on the main thread. This doesn't slow down gesture-analysis and audio computing as they happen in another context. However, when multiple fingers touch the screen, the main thread is overflowing and big latency happens (or complete destruction of the app).

I am using observable web-worker to create a pool of workers that handle the heavy lifting of computing the new pixels to generate on the canvas, a "director" thread that assembles their work and sends it to the main thread to draw on the actual canvas, at the desired frame per seconds.

I chose this library because the Observable pattern comes in very handy when handling dom-events: the TouchEvent pushes an array of Touch right through the workers and back to the main thread is a single flow, allowing other stuff to happen on a comination of events (a gesture). So the observable part of observable-webworker is a strong feature for my kind of work!

Finally, using the Scheduler API of RxJS, I can easily schedule the workers' operations on the main thread's rendering cycle (or any time-related event that the application needs to listen to).

Thanks!

[maximborisov]

Great job guys! Thanks!

[inventinside]

InventInside.com

Parametric CAD on V8, this lib allows the parallel computation of CSG tree-nodes in order to implement fast 3d geometric kernel within the browser, worker-pool lifecycle can be observed by looking at the hourglass icons appear and disappear. Thank you for your time to develop and maintain the wonderful implementation of this magic lib.

[barais]

https://correctexam.github.io/
This open source web application helps you seamlessly manage of your in-class assessments (long exam or short). Save time grading and get a clear picture of how your students are doing. Provide a clear feedback to your students.

It uses openCV in WASM and tensorflow js in WASM for image manipulation and AI.

Thank you for your time to develop and maintain the wonderful implementation of this great lib.