101–110 of 134 posts
I read the article, but I'm not sure what this technology is enabling really. Can it be thought of as a new player in the lambda/serverless category? Does it have any advantages to using other serverless stacks like aws lambda or azure?
Sounds like this could be a pretty trivial way to load balance React prerendering. As long as the react code fetches all data in 1 call it should be at least as efficient as doing it all in Nodejs on your server.
Earlier quoted context omitted.
Can I use this together with CloudFlare streaming to open up stream ingestion based on some HMAC signed parameters? To give regular end-user the rights to e.g. 'record one video of up to X seconds and Y mbps under ID "some-uuid"' I've been waiting for a proper Content Ingestion Network for ages by now... if the CloudFlare video team ever wants to talk to someone who hand-rolled their own single-node version of this I…
That's a really interesting idea!
My experience with Service Worker APIs hasn't been very positive, although I don't have any suggestions for ways it could be improved, so I apologize for the non-constructive feedback. Maybe after using it more I'll change my mind. I recognize that everyone involved is likely working hard to provide an API that's capable of handling a wide range of problems, many of which I likely haven't even considered.
Here's a more actionable complaint: fetch doesn't support timeout or abortion. I have a hard time understanding how this isn't a problem for more people. Say what you will about XMLHttpRequest, at least it supports these basic features. As an end-user, I always find it absolutely infuriating when things hang forever because a developer forgot to handle failure cases.
I'd love it if you published a locally runnable version. Aside from making it easier to configure and experiment, it would give me peace of mind to know that I could continue to use the same configuration if Cloudflare decided to terminate my service.
This sounds like a really powerful feature. I love how it uses JavaScript, which makes it much more approachable for web developers. My experience with Service Worker APIs hasn't been very positive, although I don't have any suggestions for ways it could be improved, so I apologize for the non-constructive feedback. Maybe after using it more I'll change my mind. I recognize that everyone involved is likely working ha…
https://developers.google.com/web/updates/2017/09/abortable-...
We'll be implementing soon.
Earlier quoted context omitted.
> There is a theoretical solution that we might be able to explore at some point: If compute is deterministic -- that is, always guaranteed to produce the same result given the same input -- then it can't possibly pick up side channels. Doesn't this require the timing and interleaving with other processes also be deterministic? ...which seems hard to guarantee with modern CPUs, async IO, and shared execution.
If you don't provide (real) time as an input to the program, then non-determinism of time does not affect determinism of the program. At least, in theory. It's definitely a long way from there to practice.
The timing may occur outside of your control, and then statistical profiling used. If the timing of a reponse to a network request has a time component that depends on shared load, then you have a side-channel.
Earlier quoted context omitted.
Will there be any limits on memory/execution time etc like with AWS Lambda?
Yes. Currently you get at most 50ms CPU time per request, and memory usage of your Javascript VM is limited to 128MB. These numbers may change before launch. In practice, though, a typical script probably uses much less than 1ms of CPU time per request and probably needs only a couple megs of RAM. Because we're applying limits on the level of a V8 Isolate, not on an OS process, the limits go a lot further. Keep in mi…