This is probably the best annoucement of a new feature I have ever read. It makes an analogy to an existing technology. It provides a clear description of the new feature. It provides clear examples of how to use the new feature with a link to a sandbox so you can run and modify the examples. And it explains the thought process behind the implementation. In additon, I didn't notice a single typo, spelling or grammar error.<p>Also, this feature is pretty cool!
Obligatory transformation of cloud to you-know-what:<p><a href="https://cloudflareworkers.com/#9bdc354e936c05a4a1d7df7eb0d7f672:https://blog.cloudflare.com/introducing-cloudflare-workers" rel="nofollow">https://cloudflareworkers.com/#9bdc354e936c05a4a1d7df7eb0d7f...</a>
Kudos for re-using an existing API when one was already available in the same language for a very similar usecase.<p>Any time you commit to someone else's API -- whether it's an actual industry standard, or simply some de facto widely used paradigm -- you incur risks; conversely, now that you're a vested participant, consider being involved in the future of the spec so it can evolve where it needs to meeting emerging needs around its new uses.
Paging HN user johansch from his comment on the Cloudflare Apps mitm JavaScript injection discussion 3 months ago:<p>johansch: <i>All I want is my code running on your nodes all around the world with an end-to-end ping that is less than 10 ms to the average client</i><p>dsl: <i>Akamai Edge Compute is what they are asking for</i><p><a href="https://news.ycombinator.com/item?id=14650025" rel="nofollow">https://news.ycombinator.com/item?id=14650025</a>
This is fantastic. Fastly is great but hard to use with Varnish VCL, and no other CDN had any real scripting capabilities. The service worker API is also a lot better than serverless cloud functions or lambda@edge.
Great product announcement post! I especially liked the Q&A section's reasons for not choosing alternatives.<p>Is the lack of maturity also the reason for not choosing something like vm2 for NodeJS <a href="https://github.com/patriksimek/vm2" rel="nofollow">https://github.com/patriksimek/vm2</a>
This sounds like a really powerful feature. I love how it uses JavaScript, which makes it much more approachable for web developers.<p>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.<p>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.<p>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.
Could this be used for HTTP Push across domains? I would love an easy way to take advantage of HTTP Push for assets hosted on S3 without routing requests to my origin server.
So in a way this is similar to for example AWS Lambda ? It can process incoming http requests in many ways ? Fascinating idea.<p>Is there any indication on price level ? And what about runtime duration ?
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.
<p><pre><code> - Is it "Cloudflare Workers" or "Cloudflare Service Workers"?
A "Cloudflare Worker" is JavaScript you write that runs on Cloudflare's edge.
A "Cloudflare Service Worker" is specifically a worker which handles
HTTP traffic and is written against the Service Worker API.
</code></pre>
Consufing naming convention. Now you have to say 'worker worker' or 'non-service worker' so nobody has to wonder if you meant 'service worker' when you only said 'worker'.
Oh my. Is there any form of persistence, present or planned?<p>If there is - this means that there (eventually) will be a way to have logs from the edge servers. I'm just thinking about a worker that would collect the requests and responses data in some circular buffer, and try to push it to the origin server. Eventually, the data will get through, so no CDN-returned 52x ("web server is not responding" etc) errors would go unnoticed.
So, can I use this to do this:<p>Render your SPA (different index.html) when a login cookie is set and otherwise render your landing page (yet another index.html)? - Such that that my <a href="http://example.com" rel="nofollow">http://example.com</a> can always be cached (unless it needs to hit the server where the same logic is implemented).<p>And in general, how do you manage your landing page vs. your SPA?
This is really interesting; kudos to Cloudflare for launching what seems like a cool thing!<p>Also, agree with other commentators here; nicely-written blog post!
Great addition to your services.
I really want to see the pricing.
Also I'm quite excited to see how this will play along with the apps concept. Do you plan also to introduce a monetisation system for the apps? It will be a good incentive then for developers to get some nice income.
This is really cool! I wonder if this will become the new "S3 API" and get everyone to copy^H^H^H^H implement it.<p>Also a little concerned about writing anything substantial without an onprem version!