I just stumbled upon Web Containers, which is essentially one company’s effort to port node.js to the browser using WASM:
Here’s where it gets interesting, esp. in regards to Sockethub, and maybe also local RS servers:
WebContainers include a virtualized TCP network stack that’s mapped to your browser’s ServiceWorker API, enabling you to instantly create live Node.js servers on-demand that continue to work even when you go offline. Because it runs entirely within the browser security sandbox, server responses have less latency than localhost
If I understand this correctly, it would mean that we could run Sockethub locally in the browser, alongside unhosted web apps, correct?
Yeah Redis is for processing large amounts of requests from multiple users. If we have just one user, we could probably just implement a simplified startup mode (--web-container)? which would still do the websocket->schema validation then skip the separate platform processes & redis, and go straight to calling the platform.
I wonder how it behaves though with TCP sockets, this is one of the issues with running anything in the browser, the browser sandboxes code against opening non-web ports. I imagine this operates within the same set of restrictions, though I haven’t been following browser tech as closely as I was a few years back, so things could have changed in this regard.
Yeah, so that’s the big question. They make it sound as if everything just works, but I thought SW are still restricted to Web APIs like Fetch and WebRTC.
It’s as we expected: only HTTP connections are possible. Calling that a “virtualized TCP network stack” is just hyping it a bit too much.
We’re limited by the browser’s ability to make network requests, so connecting to processes like MongoDB, Redis, PostgreSQL, etc. are not currently possible. This may change as Chromium plans to ship Native Sockets in the future. For now, we’re limited to HTTP connections, but we’re able to support other protocols that run on HTTP such as WebSockets. HTTP requests to external services must be allowed with CORS or a CORS proxy.