Single instance on multiple tabs

[nikeee]

Is your feature request related to a problem? Please describe.
From the source, it seems that this library wraps a normal Worker in case there is no SharedWorker.
However, a SharedWorker is only instantiated once per origin/url. Does this library handle this as well?

Describe the solution you'd like
One tab could host the actual worker and the other tabs could be tricked into delegating everything to a BroadcastChannel, which the Worker also listens on.

Describe alternatives you've considered
None

[okikio]

Sorry for the late response, I've actually been thinking about this for a while, and you're correct I'll get right on it

[nikeee]

Thanks for your reply!
I just had a thought on that and noticed that it might not be that easy if the user closes the initial tab.

Can I help somehow?

[okikio]

Sure, I'm about to have a coding sesh, you can join if you'd like

[nickchomey]

My issue is similar to this.

Right now, I'm thinking of creating a "SharedWorker" within ServiceWorkers by only allowing required actions (in my case, network requests to the backend server) to be performed by the ServiceWorker associated with the first opened tab for an origin. The other tabs will register the requests in an IDB store request-queue via Dexie.js (which I'm already using), then periodically the master Service/SharedWorker will process the requests in one batch request (with server-side code handling the various requests and returning them in JSON which can be parsed by the Master SW and saved in a queue-responses IDB store. The other tabs will receive updates via the LiveQuery mechanism introduced in Dexie 3.2. It seems like it'll work but its clearly an overly-complicated kludge.

I'd be curious to see what you guys can come up with for this - perhaps BroadcastChannel would be a simpler mechanism! Though, I suspect my method will be necessary for my needs, since I'm not so much trying to sync tabs as consolidate unique network requests into a single batch request.

Edit: Now that I think of it some more, I'm not even sure a SharedWorker could even do what I'm looking for. I just figured through some async/await mechanism the ServiceWorkers would just wait for the SharedWorker to process the various requests. But it really might just be necessary (or at least prudent/robust) to have that IDB queue in the middle...

Edit 2: Or maybe it actually is all quite similar - LiveQuery uses BroadcastChannel for part of its magic. Hopefully my ramblings here provide some spark!

[okikio]

@nickchomey Why not just use cache storage to store responses and check if a response has already been cached, it's what I used for bundlejs.com

• https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage
• https://github.com/okikio/bundlejs/blob/main/src/ts/util/fetch-and-cache.ts

[nickchomey]

Thanks for the suggestion!

I already am planning to use cache storage or, more likely, IndexedDB to store responses. This particular mechanism is for a periodic call to the server to check for any updates (its a highly dynamic site with social networking etc...) and each tab will be looking for different updates. So, rather than have each tab sending a request every minute (on its own schedule, depending on which second of the minute each was opened), I'd like to consolidate all requests into a single request that is sent to the server at, say, 0 seconds of each actual minute of the clock.

Benefits of this are:

• If the same page is open on two tabs, they'll update at the same time rather than out of sync (as it currently works).
• Surely reduced overhead for the client browser
• Considerably less server overhead, since none of this is happening with an efficient REST API endpoint (its a wordpress site, so each request bootstraps the entire wordpress mechanism in order to retrieve one piece of data - why not retrieve all the data required by all tabs in one request?).

Perhaps someday I'll implement some WebSocket mechanism that'll obviate the need for all of this, but it won't happen for now. And, moreover, perhaps someday I'll implement a sort of Headless WP that purely uses REST API or GraphQL, but again not for now.

So, this seems like a reasonable approach. In fact, it seems pretty much equivalent to this JSON Batching mechanism that Microsoft has. I also use a similar mechanism with Elasticsearch's mget (batch query) API - one request from the webserver performs many search queries across a variety of indices, which php then parses and combines as-needed before being sent to the browser.

Sorry for surely cluttering the discussion here, but I hope that it provides a spark of inspiration in some way!

[okikio]

I would be hesitant to use IndexedDB, it's less reliable than Cache Storage, plus Cache Storage is meant for storing large pieces of data, so you may want to look into it

[nickchomey]

Thanks. I will experiment with both, but I strongly suspect idb is the way to go for my application. It supports more granular querying and Dexie makes it easy, flexible and robust to use. Idb also has larger storage limits and I believe longer persistence is possible as well.

[nickchomey]

I'll let you folks know if I can figure out this SharedServiceWorker via dexie thing. It might be a decent solution for chrome for android and other incompatible browsers.

[nickchomey]

Looks like the RxDB package already implements pretty much exactly what I had tried to describe - they call it Leader Election, which itself is an already-defined software pattern. They talk about it in their discussion of Multi-tab support as a potential solution to the lack of SharedWorker support in browsers.

The free version of RxDB works on top of Dexie, so looks like I'll be using that..

Hope this helps!

[okikio]

Awesome, I'll look into that

[ForbiddenEra]

I just noticed this issue, I had started developing a ponyfill for this purpose (inspired by & links to this repo) using leader election and broadcast channels for browsers that don't support shared workers.

I did get it working but it could've been better; I'm re-writing it now and it should end up as more of a polyfill than a ponyfill so from a worker script's perspective, it'll be no different than a real shared worker with some caveats of course, such as if the leader tab gets closed, the worker will then get re-started in a different tab and that my implementation seemingly doesn't care whether the worker script is classic or module, either will work thus setting the type in worker options isn't really needed.

It is indeed much more complex and I ran into a fair bit of edge cases when first implementing it, haven't ran into all of those in the new re-implementation yet though. One being that in one browser (chrome? iirc?) if the window was minimized/not completely visible, that it would lower worker priority thus making timers execute much slower and initially leader election was based on a ping timeout algorithm to know if a worker was closed/stopped responding; with the re-implementation, I haven't seen that issue just yet though I'm considering alternatives if I can get them working reliably.

My personal use case was wanting to have a single shared websocket connection across all tabs; serviceworkers won't let you do this, sharedworkers are great for it but aren't supported in some cases and simply polyfilling with a dedicatedworker defeats the goal of having a single websocket connection (thus defeats the main purpose of even having websockets in a worker)

Not sure if there's any interest here in my implementation but I thought I would at least mention it for discussion purposes.

[okikio]

Oh, wow, yeah I'm interested. I was working on that very thing a couple months ago but I ran out of time and haven't been able to go back and try to implement this 😅