Hacker News Reader

Comment by rubenfiszel | Hacker News Reader

This is great, thank you for open-sourcing. One limitation is see with this model which is clearly stated in the post is that it is javascript/wasm and HTTP servers only. The deployable workers model is a great one and I had hoped to provide an adapter for the open-source windmill[1] project by transforming the normal scripts that are our units of execution into http servers runnable in workderd.

We support typescript (deno), go and python. Short of those languages becoming 100% transpilable to wasm, we will have to fallback to use firecracker or keep our current system implemented from scratch using nsjail for sandboxing and a fork for each process.

[1]: https://github.com/windmill-labs/windmill

View on HN

Regarding the HTTP limitation, we are working towards adding raw TCP and other protocols soon. (I know we've been saying this for a while... too much to do, too little time, and this one got reprioritized down the list a bit, but is getting close to the top again.)

But as far as JavaScript/Wasm, that's a pretty inherent design feature to the Workers architecture. Cloudflare will probably provide containers eventually but that'll likely present itself as more of an add-on than a core part of the platform.

The problem is, containers are just too heavy to support the nanoservices model as described in the blog post. JavaScript and Wasm are really the only viable options we have for something lighter-weight that meets our isolation needs. Other language VMs are generally not designed nor battle-tested for this sort of fine-grained isolation use case.

Adding raw TCP is a big deal, it skips all the existing security stack that focuses on HTTP/S. There is Spectrum and Transit to provide network level protection but... only a few can afford that.

Does this mean that TCP workers would be exposed to network level attacks or would it use transit/spectrum? If it turns out to be protected; I'd say there would be little to no reason to use Spectrum unless the pricing turns out to be atrocious for long lived connections (which is kind of the point of having TCP workers in the first place).

I hope I did not come out as rude; I'm genuinely curious about what's the plan behind all of this.

Edit: I pointed out there would be no use for spectrum since one could "easily" build a reverse proxy with a tcp worker.

The exact details aren't all nailed down but I'd expect for incoming connections Workers would integrate directly with Spectrum. I don't know what that might mean for pricing, but I imagine we'd find a solution where cost doesn't block people from building cool things.

Reply on news.ycombinator.com