4 ms·
Exciting times! Seems it's all about making a product that sells the features of serverless in the right way. Technically I would like websockets on these platf
by emj 9y ago
Exciting times! Seems it's all about making a product that sells the features of serverless in the right way. Technically I would like websockets on these platforms, but I don't know how to sell that as a feature.
These numbers 50 ms of compute time and 15 s idle are interesting in the serverless space. Now I'm waiting for sane performance suites to figure out what suites you, I'm guessin this solution will kill in these strange latency test for AWS lambda from the other day: https://news.ycombinator.com/item?id=16542286 https://news.ycombinator.com/item?id=16542286
- kentonv 9y ago> Technically I would like websockets on these platforms FWIW that's something I'm working on. It's tricky because it's not actually in the Service Workers standard. Currently, we support WebSocket pass-through (so if you do something like rewrite a request and return the response, and it happens to be a WebSocket handshake, it will "just work"), but haven't yet added support for terminating a WebSocket directly in a Worker (either as client or server).
- jkarneges 9y agoFanout (https://fanout.io https://fanout.io) is useful for handling raw WebSockets from a FaaS backend. Getting it to work with Cloudflare Workers is a little more involved since our Node libraries don't run in their Service Worker environment, but if you implement the negotiations manually it does work.