State of WebSockets in Workers

Hi!

I read a couple of older threads about WebSockets in Workers:


Following that, I also found this GitHub issue discussing WebSocket support in ServiceWorkers: https://github.com/w3c/ServiceWorker/issues/947

Both of these discussions are at least a year old, so I was wondering if there are any updates on this.
From what I understand there were two problems:

  1. There’s no standardized API to intercept WebSocket traffic in ServiceWorkers. Cloudflare would need to come up with a custom API which might be harder to learn and would mean that Workers get harder to test.

  2. Billing would get more complicated.

I can’t say anything to the second point but it seems like the first problem isn’t going to get solved anytime soon. From what I read, there are no plans to integrate WebSocket interception into ServiceWorkers.

So I guess the question would be, how high does the demand for WebSockets in Workers need to be, in order for Cloudflare to justify a non-standard API? And as far as testing goes, could that not be solved with better tooling? Can the Workers team share thoughts on WebSocket support and maybe their upcoming roadmap?

Thanks a lot! Looking forward to your replies…

5 Likes

I am curious about this as well, websocket support in workers could be a great way to easily scale highly available websocket servers around the globe that interact with a persistent storage like firebase, which I would like to do for a matchmaking service. For now im looking into a rest service instead.