Allow authenticated fetch in a Web Worker

[RubenVerborgh]

Many Web applications perform tasks in a Web Worker, and this includes fetching.
Therefore, it would be useful if this library's fetch would also function in a Web Worker.

Of course, the library cannot fully do everything in the Web Worker (since logging in involves redirecting etc.), but if the fetch functionality could be transferable to worker, that would be great. One option for this is that the required settings can be serialized as a JSON object in the main window, and then be reconstructed in the worker.

[dan-f]

Good idea! Could you help me by providing two details?

1. From what I can tell, all the necessary interfaces that the exported fetch makes use of are available in a web worker. What's the blocker here?

2. What's the particular use case you are thinking of? I generally think of web workers as being used to accomplish "heavy lifting" tasks, like processing large amounts of data. I'm not really sure if we'd see much real-world benefit to moving an async HTTP request from the main thread to a web worker.

[RubenVerborgh]

From what I can tell, all the necessary interfaces that the exported fetch makes use of are available in a web worker. What's the blocker here?

localStorage is not available in a Web Worker, so I don't think the Web Worker would have the authenticated fetch.

What's the particular use case you are thinking of?

http://client.linkeddatafragments.org/ 😄

I generally think of web workers as being used to accomplish "heavy lifting" tasks, like processing large amounts of data.

Exactly, and this also involves fetching that data.

I'm not really sure if we'd see much real-world benefit to moving an async HTTP request from the main thread to a web worker.

Not for the request itself, but the fact that the main thread does not need to send the resulting data to the worker.

[dan-f]

Ah I see, the problem is localStorage. Odd that indexedDB is available, but not local/session storage.

Exactly, and this also involves fetching that data.
...
Not for the request itself, but the fact that the main thread does not need to send the resulting data to the worker.

Yeah I'd be curious as to how "bad" it is, in practice, for HTTP responses to call back to the main thread when all that the main thread is doing is handing work off to a worker in another thread. For a use case like the LDF client, you'd get a lot of callbacks added to the callback queue, but they'd complete super quickly.

[RubenVerborgh]

a lot of callbacks added to the callback queue

Yes, and a lot of data being switched between threads (I presume).

[dan-f]

So after discussing, it looks like the smoothest way of accomplishing this (minimizing API changes) would be to swap out localStorage for IndexedDB. That way this lib can be easily loaded into a web worker.

[dan-f]

More catchup from offline discussions - we're moving towards augmenting the storage API within this library to return promises, rather than immediate values, in order to allow implementations of the interface to communicate across threads.

[dan-f]

@RubenVerborgh I think this should be supported with the changes that landed in #24 (by constructing an async storage interface on top of postMessage). At some point, would you be able to test that?

[RubenVerborgh]

Yes, that should definitely be possible. Might even reuse some of the existing postMessage logic. Will need this in the future, so I'll definitely come back to this.

[elf-pavlik]

I start playing with https://github.com/PolymerLabs/actor-boilerplate
Explained in this recent Google Chrome Devs video: https://www.youtube.com/watch?v=Vg60lf92EkM

They also recommend as rule of thumb to only use the main thread for UI (DOM, canvas etc.) related functionality. I think many people would want to run actors using solid-auth-client in a web worker (sometimes also Service Worker) solid/solid#143