rita3ko

(confession: i work at cloudflare)

but we just made our first announcements for this week, including: - d1 (our serverless database) going GA - hyperdrive (SQL query cache for postgres and mysql) going GA - and workers analytics engine

if you just moved off google domains, i recommend checking out cloudflare pages, which is cloudflare's product for hosting static and dynamic sites (with gitops, everything else included).

you can do both! all of our models are supported either via workers / pages binding (which makes it really easy to host the rest of the logic), and via REST API

docs: https://developers.cloudflare.com/workers-ai/get-started/res...

(llama specific example here too under curl: https://developers.cloudflare.com/workers-ai/models/llm/ )

we always are! email is rita at cloudflare dot com :)

stay tuned!

we (cloudflare) have a great example of a vector database build on workers + kv here: https://ai.cloudflare.com/demos/vector-store/

(plan to talk about how we built it soon)

edit: clarify i work at cloudflare

What details are you looking for? Maybe we can fill you in :)

We still have some work to do to get the runtime ready to open source and make it broadly available, but happy to answer any questions we can.

it sure is: https://boards.greenhouse.io/cloudflare/jobs/3156953?gh_jid=...

Pages itself has been GA for a little while now (https://blog.cloudflare.com/cloudflare-pages-ga/). For the integrations with Workers, it's TBD (we generally want to leave things in beta for a bit and let it bake in before giving you the thumbs up to put your production site on it), but we move fast, so likely sometime in the first half of next year.

hi there! i'm on the workers team at cloudflare.

you're right that the ideal application would run fully on the edge (which is why we try to offer things like KV, Durable Objects, and more options in the future for you to have your data where your logic is running).

however — moving your data to the edge is unlikely to happen overnight. and it's going to take us a bit to offer you all the data options for all the different use cases that you need (after all, there are many types of databases for a reason), so this gives users greater optionality. secondly, if your data is already somewhere but you want to build new features on top of it, now you can. (say, i already have a database with all my apartment listings in it, but i want to add a new feature where i let my users add photos of the apts). i can now build that feature in workers, without having to undergo an otherwise massive migration.

one last thing, this is just the beginning of what even database connectors mean. in the future, we can cache data, and actually improve performance and reliability even if the dc is far (as you said, make it easier to have best of both worlds).

also a good time to mention that if you build something in in rust using workers, you should submit it to win some free swag:

https://challenge.developers.cloudflare.com/

jam.dev are good friends of ours (both founders ex-cloudflare and some of my good personal friends!) :) but was thinking about it more as a play on jamstack.

re: excluding branches — we're actively looking into it!

and yes, that error has been fixed AFAIK, but let me double check.

Yes, it's included in the existing plan if you already have Pro / Business.

There's a bit of background here https://developers.cloudflare.com/pages/migrations/migrating...

TL;DR: Workers Sites is basically an elaborate Worker template (which you can modify) and allows you to deploy your sites using the Wrangler CLI — it'll take care of uploading your assets and all, but you're responsible for setting up CI, etc for a continuous deployment experience.

Cloudflare Pages, by contract, integrates directly with Github, which allows us to offer a lot more features out of the box, including running your build, preview URLs, etc.

Hope that makes sense.

Hey there. I'm the PM for Pages. That's fair feedback (though a lot could have changed even in the past few weeks, so I would recommend taking another look)

- It's hard for me to tell what's causing the issue (the build logs should give an idea of at least at which stage). One thing we've added over the course of the beta is connection to GH comments, which requires a new type of permission. So that might be causing the failure, but also, failed builds should result in a comment (and email) for notifications, depending on your GH settings. All of that said, my email is rita at cloudflare if you want to forward me more details, I can help look into it.

- Creating a canonical notion of your domain is something we're thinking about. Right now the preview links will set X-Robot-Tag so they can't be crawled but yeah, ideally we want to give you a way to remove myproject.pages.dev if you're not using it

- The cache-control settings are intended to keep your site from serving stale content by relying on etags — your browser should still serve from cache if the asset hasn't been updated. On the Cloudflare site, we have much longer TTLs.

Anyway, thanks for trying Pages! We're continuing to iterate on it, even after GA so should only be getting better :)

(edit: spacing :P)

hi there! cloudflare pages pm here :) we certainly plan to (nothing against gitlab!!), likely in the next couple months. my email is rita at cloudflare. happy to keep you posted

Genuinely curious — what would you expect to get from containers that you can't get from building on Workers + Pages as described above?

Sorry about that — had to keep them separate to avoid spoilers ahead of launch, but trying to avoid a migration on launch day.

To satisfy your curiosity though for our Gatsby setup, you can actually check it out here: https://github.com/cloudflare/cloudflare-docs (the rest of our docs are open source and built in the same way, the Pages docs will just go there as a subdirectory, same as the other products).

Doc engine itself is here: https://github.com/cloudflare/cloudflare-docs-engine

You're just one step ahead of us :)

We'll be working on building in one-click configuration to have Cloudflare Access in front of your preview deployments specifically for this purpose.

More good news: we support private repos today :)

Hi there, I'm the PM working on Cloudflare Pages. We don't have support for this now since we're still in beta, so not everything is there yet, but it's certainly a use case we intend to support. You'll just be able to specify no build step. :)

Hi!

I'm a product manager working on Workers — didn't come across hater-y to me at all.

We will actually be rolling out a new version of our docs soon — hopefully make them easier to navigate, and expose deeper information. If there are any specific subjects or corner cases you've run into that you'd like to see better documented — our docs are open source (so issues are welcome!). We definitely want to make it as easy as possible for you to self-service.

Observability and debugging is also a heavy area of investment for us (and I think we've made significant progress here since the launch of Workers). As Kenton mentioned below, wrangler tail is a great way to get a lot of information out of the Worker (and its subrequests) — you can basically log anything. We'd also like to make it easier to log to existing logging platforms from a Worker. If there's any missing information you'd like to see, please do sent me a note ^

It’s not so much that we’re avoiding it, as much as we think there are more interesting things for us to accomplish. We could double down on hosting static sites, but that’s only one use case of the realm of possibilities of what we can achieve with compute on the edge with Workers. We’re excited for people to get their hands dirty, and see where else they take it.

We can probably help. Vary is usually intended to shard the cache based on parts of the request. You can do the same with the cache API - modify the cache key (quite similar to the example for caching the POST request (https://workers.cloudflare.com/docs/reference/workers-concep...), as you modify cache key to match the POST body).

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.

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

I might misunderstand what you mean by third party service, but today you can connect to any service on the Internet (including databases like Firestore) with Workers using fetch() [1].

We're building out our storage products -- we started with Workers KV, our distributed Key-Value store, and will to continue expanding our offering to support more use cases. You won't be able to build everything with Workers right away, but we've seen customers solve really interesting problems with it. As we add functionality to support more and more use cases, we expect Workers to grow into a really powerful platform.

Note that Cloudflare Workers is a different product from Cloudflare Apps (which is what you see on the Marketplace). Cloudflare Apps does allow developers who want to distribute their Worker to other Cloudflare customers to do so, using Apps with Workers.

[1] More on fetch() here: https://workers.cloudflare.com/docs/reference/runtime/apis/f...

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.

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.

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.

Hi! I'm the PM for Cloudflare Workers. Happy to answer any questions about our announcements, or Workers in general.

Full disclosure - I work on Workers at Cloudflare, so obviously biased :)

There are a lot of performance advantages along every step of the way, as you mention. I think you can look at this from many different lenses beyond performance.

A big advantage was how fast and easy this was to get up and running. Simplicity is key here - it's a simple API written in JavaScript (no config, VPS, etc necessary).

The other really important thing is scalability - when workers.dev went live, we didn't have to worry about being able to handle the spiky workload (preregistration sites end up failing quite frequently). This scales infinitely.