News for hackers. Stuff that matters.
Re:Cloudflare Workers by rita3ko on Sunday June 02, 2019 @06:18AM (#20074564)
Hi! I'm the PM for Cloudflare Workers. Happy to answer any questions about our announcements, or Workers in general.
Re:Cloudflare Workers by tadeusz_wojcik on Sunday June 02, 2019 @01:51PM (#20076912)
I'm using workers since beta, including KV storage, it's great overall. Unfortunately recently noticed (testing for production launch) that there are rate limits in place (something around 2k requests per minute per IP for requests that go trough to origin server) - known issue it seems - https://community.cloudflare.com/t/rate-limit-on-workers/495... . I've contacted support already, ticket is marked as 'solved' but I still experience limits (429/1015 error codes). I'd love to know if it's something to be expected and if someone is planning to run tens or even hundred requests per seconds from single IP (I have bit weird API to work with that requires that) it's better to not use workers as it's not intended scenario? Or it's a matter of having more expensive Cloudflare plan (I'm on 5$/month for workers)? Would really appreciate more details on that subject as can't really change that API and will constantly run into 429 errors.
Re:Cloudflare Workers by zackbloom on Sunday June 02, 2019 @03:55PM (#20077676)
There are various mechanisms like this in place to make Workers an unattractive way to launch an attack. tadeusz_wojcik also emailed us, and we were able to raise the limit for them (and anyone else who asks!).
Re:Cloudflare Workers by tadeusz_wojcik on Sunday June 02, 2019 @04:09PM (#20077774)
yep, I can confirm. Excellent communication on Zack's and Kenton's side. After limits were lifted everything is working perfectly - no more 429 errors. Thanks again!
Re:Cloudflare Workers by StavrosK on Sunday June 02, 2019 @08:55AM (#20075161)
I was excited to try out WASM workers (thanks again for your help in getting me set up!) but when I ran the Rust example, I realized it's only half-ready. The `request` object isn't passed into the Rust function, and there's basically no documentation about how things would work on the Rust side.

I was hoping I could get a Rust template and not have to touch any JS, just change the Rust side of things. However, it looks like all the template provides is some instruction on how to call a function without arguments, which is not very useful.

I know this might be out of scope of the template, but I think it kind of defeats the purpose of saying "We support WASM!" if it implies "but you're going to have to know JS and figure out how to actually use WASM". If I knew JS that well, I would have just used that.

Re:Cloudflare Workers by steveklabnik on Sunday June 02, 2019 @09:08AM (#20075207)
We’ll be doing more here, for sure. Start small, iterate from there :)
Re:Cloudflare Workers by yeppie on Sunday June 02, 2019 @07:19AM (#20074784)
Do you have plans to provide a Workers KV interface that would allow us to search for keys, as well as view, modify and create new KV entries?

Also, it's currently only possible to avoid leaking that multiple websites belong to the same entity by creating multiple Cloudflare accounts due to the nameservers. This means that if we want to use Cloudflare workers for our 5 unique nameservers, then we would have to do a lot of unnecessary duplication. So on a somewhat unrelated note, do you have any plans to add support for adding additional nameservers to a Cloudflare account (this is currently holding us back from using Workers over Lambda, and it's something we would gladly pay for).

Re:Cloudflare Workers by judge2020 on Sunday June 02, 2019 @08:14AM (#20074992)
> additional nameservers to a Cloudflare account

The price point may not be ideal but Business plan websites can set up branded subdomains (eg ns1.example.com, ns2.example.com).

Also, there are a limited amount of nameservers (2550 possible combinations with 50 male and 51 female nameservers I believe), so there’s probably a few thousand other accounts with the same combination of nameservers as you. This can still be a problem though, if you use a less-common TLD and/or you use pages with similar content.

You could try using the API to automate this across multiple accounts https://api.cloudflare.com.

Re:Cloudflare Workers by yeppie on Sunday June 02, 2019 @09:49AM (#20075418)
It's definitely a problem for us, although it's fewer nameservers than I expected :)

No idea how I missed custom nameservers on business plan.. Hope it's something they added this year, otherwise I feel quite embarrassed.. It's too pricey for personal use (since the plans are associated with websites and not accounts) but the company will probably upgrade a few of the websites, thanks!

Re:Cloudflare Workers by steveklabnik on Sunday June 02, 2019 @07:22AM (#20074795)
I’m the PM on Workers KV. We do have plans for better tooling here, though I can’t promise exact details or a timeline. I can tell you that I feel the pain of the lack of that stuff, though.
Re:Cloudflare Workers by hanniabu on Sunday June 02, 2019 @07:28AM (#20074819)
Lol well generally speaking, when the PM feels the pain it gets done sooner rather than later
Re:Cloudflare Workers by steveklabnik on Sunday June 02, 2019 @07:30AM (#20074825)
In some sense, that's true, but it's also my job to make the best thing for everyone, not the best thing for me personally :)
Re:Cloudflare Workers by seanlaff on Sunday June 02, 2019 @06:31AM (#20074607)
The v8 isolates tech is super cool. It seems the other major providers might not be leveraging it in their FaaS platforms- do you have a hypothesis of why?
Re:Cloudflare Workers by rita3ko on Sunday June 02, 2019 @06:37AM (#20074625)
We're starting to see similar technologies emerge (like Fastly's Lucet). My hypotheses (please take them as that): 1. Many companies are already deeply embedded and invested in container based offerings. 2. As with every new technology, it takes some time for it to take off. Maybe others are hesitant and waiting to see how it plays out for Workers before investing (going pretty well so far :) ). 3. Possible the other providers are working on it, and haven't launched yet.
Re:Cloudflare Workers by toinbis on Sunday June 02, 2019 @03:12PM (#20077366)
With the release of wrangler and new docs we finally have the router app starter template. I wanted to ask if you could go one step further and share the template which would include middleware functionality implemented. By middleware I refer to what middleware stands in Django web framework.

Many of the app functionality, such as language/locale based cookies, url-level a/b-tests, etc. is shared between all the routes, and it would be nice to have such logic described somewhere in separate place, not in the route handler functions. For non-pro developers like me that'd really help.

P.S. In case no one has mentioned this yet, community is really thankful for allowing multi-script for everyone, not only enterprise users. Enterprise features for free or 5$ - that's a very generous pricing, to say the least! Thanks.

Re:Cloudflare Workers by kmf on Sunday June 02, 2019 @07:17PM (#20079057)
Hey - developer advocate for Workers here. Thinking a lot about this right now, prototyping a few ideas too. If you have ideas, happy to chat: kristian@cloudflare
Re:Cloudflare Workers by maltalex on Sunday June 02, 2019 @07:53AM (#20074909)
What compelling use cases have you seen for this technology?
Re:Cloudflare Workers by rita3ko on Sunday June 02, 2019 @08:26AM (#20075035)
It's been really interesting watching the evolution of use cases for Workers.

I would put them into three broader categories: 1. Additional functionality built on Workers: the interesting thing with Workers is that it can be a standalone function, or it can act as a proxy. That means that customers can easily add new functionality on top of existing APIs for example, without having to migrate the whole thing to Workers at once. One interesting example of that was an e-customer used Workers to add a barcode generator funcionality for one of their customers.

2. Applications built on cache: the way CDN usually works is that you build an application, and put a cache on top of it. That comes with all sorts of limitations around what you can and cannot cache. I think with a built in cache, we're going to start seeing more cases where the cache is written to from the beginning. This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin. Or easily update only certain chunks of what's in the cache, and thus do all sorts of customization at the edge, without necessitating added latency.

3. Standalone serverless apps: there are a few very interesting examples here, one of which we'll be able to talk more openly about in a few days. I think SamKnows is a good one: they were able to build a download speedtest directly from Workers [1]. Another good one was building the reservations website for Workers.dev - we were able to get that service spun up very quickly, and have it scale infinitely to handle the influx of traffic [2]. Similarly, Cloudflare Access is built entirely on Workers (we are pretty excited about dogfooding!).

A couple random cool ones: I've seen some experimentation with ML on the edge (very much POC, and very early, but everything starts somewhere). And DNA sequencing analysis, which really blew me away [4]

[1] https://blog.cloudflare.com/the-samknows-cloudflare-platform... [2] https://blog.cloudflare.com/api-at-the-edge-workers-and-fire... [3] https://blog.cloudflare.com/building-serverless-apps-with-wo... [4] https://twitter.com/RobAboukhalil/status/1121095204281430016

Re:Cloudflare Workers by treis on Sunday June 02, 2019 @08:47AM (#20075128)
>This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin

I don't get how this would work. For someone logging in you still have to talk to a central database holding the authentication information. Really anything with a database has a similar problem if you want to enforce consistency.

To use the subdomain example, say you want to prevent two people from reserving the same name. That means the reservation from someone in Sydney has to propogate to the worker in NYC before you can confirm that it has succeeded. Otherwise, simultaneous reservations will result in two successful reservation. So you've lost the benefit of edge workers.

Re:Cloudflare Workers by rita3ko on Sunday June 02, 2019 @08:58AM (#20075175)
Sure, the initial login itself has to be done at the origin, or connect to a database, but token authentication can be done at the edge. That means that if, for example, users have to pay for articles, you can still cache the article because the authentication can be validated at the edge.

There are many benefits to running logic at the edge, even in situations like that. Scale is a big one to consider: resiliency and single point of failure are very common problems for any floodgate reservation systems. We didn't have to worry about that here.

In general, the more work you can offload to the edge, the better. There's so much logic that goes into handling a reuqest - we see many customers with conditional HTTP routing, validation, rate limiting, etc -- all requiring round trips to the origin. Now they can be done close to the user.

Re:Cloudflare Workers by Spiritus on Sunday June 02, 2019 @06:23AM (#20074581)
Do you have plans to add support for more languages besides JavaScript and Rust down the line, e.g. Python?
Re:Cloudflare Workers by rita3ko on Sunday June 02, 2019 @06:32AM (#20074610)
Not for the time being - to allow us to run code on the edge, and be able to support many customers, we used V8 (a JavaScript engine) since it built for multi-tenant-per-process secure sandboxing, fast start time, and low overhead (a lot of this is explained in the original blog post here: https://blog.cloudflare.com/introducing-cloudflare-workers/).

We are working on improving our WebAssembly integration, and making it a first-class experience (and we launched multiple improvements with the CLI to allow you to more seamlessly develop in Rust, C and C++). Maybe one day Python WebAssembly will take off.

Re:Cloudflare Workers by fniephaus on Sunday June 02, 2019 @07:11AM (#20074740)
Have you had a look at GraalVM? Their native images [1] allow compilation of JVM-based languages into binaries with fast startup behavior and low memory footprint.

[1] https://www.graalvm.org/docs/reference-manual/aot-compilatio...

Re:Cloudflare Workers by steveklabnik on Sunday June 02, 2019 @08:09AM (#20074971)
GraalVM is really awesome, but it doesn't fit what we're trying to do here. One of the key bits of architecture is that we share the VM between all of the programs; this saves on a lot of overhead. Running multiple native images would still give a copy of each runtime for each thing.

(Also, while native images may have low memory footprint themselves, that doesn't mean that the programs that use them have a low enough memory footprint; my understanding (which may be wrong!) is that the default heap size it sets is 80% of the memory of the machine you're compiling it on. You can of course tune that, but it's gonna be tough to squeeze in a memory-hungry application.)

Re:Cloudflare Workers by toinbis on Sunday June 02, 2019 @10:37AM (#20075704)
Thanks for release and making such inovation affordable for all of us. Just to clarify on the new "multi-script" feature and "30 scripts" limitation:

- same worker scripts are shared between CF account level and workers.dev.

- script belongs to account, not domain.

- 30 scripts limit is for account (CF/workers.dev).

- Routes for domain are unlimited.

Are all of the above statements correct?

Thanks!

Re:Cloudflare Workers by lucasverra on Sunday June 02, 2019 @07:55AM (#20074919)
Hi there, thanks for sharing data this sunday.

How is this better CDN for functions than netlify's and its dev/offline-simulating tooling ?

Maybe prices (your free tier seems overly generous) ? but Assume my interest dont go < 10K req / day, it that would be the case i would monetising somehow

Re:Cloudflare Workers by StavrosK on Sunday June 02, 2019 @07:21AM (#20074791)
I've pre-registered for two subdomains, clicked the email, logged in to my account but I can't add them because it says they're "taken" (by me, presumably). How can I add the subdomains I reserved?
Re:Cloudflare Workers by rita3ko on Sunday June 02, 2019 @07:25AM (#20074805)
Are you using the email that you made the reservations with? We do the match on that. Otherwise, if you want to shoot me an email at rita at cloudflare dot com, with the subdomains / email you signed up with, I can look into it.
Re:Cloudflare Workers by StavrosK on Sunday June 02, 2019 @07:32AM (#20074832)
Emailed, thanks!