[Feature Request] - rpc like communication for Web API Workers

[Bloodiko]

tldr: Using this to communicate efficiently with Web API Workers, which basically use the same "Websocket" structure, might be a nice feature for this lib.

Explanation

Currently, the library expects an web endpoint http or a Websocket endpoint.
Using this library, to utilize rpc to efficiently pass (heavy/ async) work between the main context and a web worker (Web workers API ) could make the existing API much easier.
Additionally, the difference between a Websockets send() (with strings only) and the Web workers postMessage() are relatively marginal.
Therefore I assume it could be utilized to allow the same behavior for Web workers.
Http connection --> worker.postMessage()
Websockets connection --> worker.connect()

caveats

To be fair, I have no idea how you would be able to tell it to connect to an worker instead of an Websocket/http endpoint.
Maybe by passing the web worker object to the connection creator?

Please tell me your thoughts about this idea.
Curious if that would be possible.

[bjesuiter]

To the topic of init

Maybe we can do the initialization like drizzle does with db connections?
They have the "drizzle" command, imported from the various db providers, like
‘import { drizzle } from "drizzle-orm/node-postgres"‘
And the available options differ depending on the package this thing comes from. If passing one string, it's normally used as db url, if passing an object it's a whole config which also support advanced options.

Basically, we'd have a shared core but adapters on top.
I'm not sure if this will bloat the library too much, but it could be tried.
I'm thinking about this library being also extremely useful in a ServiceWorker, for example in chrome extensions.
So being able to write "plugins"/"adapters" for this library like the db drivers for drizzle would be useful imo.

To the topic of serialization

As a first step I'd also be happy to only have strings. This is still better than using it per hand imo, supporting StructuredCloning and Transferable objects could be a second step which optimizes performance and increases capability of this special mode.

[kentonv]

Hey @Bloodiko, please disregard the "Albert Hilton" guy who is not affiliated with our project.

Communication with a Web Worker (not to be confused with Cloudflare Workers 🙂) should work today using the MessagePort transport.

1. Create a MessageChannel (which is a pair of MessagePorts).
2. Use Worker.postMessage() to post one of the two ports to the worker.
3. Use newMessagePortRpcSession() to create an RPC session around the other port.
4. In the Worker, upon receiving the postMessage(), use newMessagePortRpcSession() to create a session on that end as well.

Voila, you now have an RPC session with your Worker. Moreover, since the RPC is over a separate MessageChannel, it doesn't interfere with any other postMessage() communications you might want to perform with the worker.

[kentonv]

^ @bjesuiter FYI the guy you were replying to was an impostor. :( This is the real answer.

[Bloodiko]

Okay this is cool. Will definitely try that.
That sounds amazing.