It orchestrates you and your customers' code by allowing them to run custom code after specific actions. For example, HackerNews could implement this and allows us to run any code right after we post a comment, so we could send an email, call an api, perform a database call, etc.
What's the benefit? You don't need to set this up yourself (security, authentication, validate tokens, create endpoints).
Why don't create an API so we have more control rather than give customers the ability to run any code? Well, it depends. If you can keep up with customer requests, then go ahead with an API. If you have a lot of requests and it's becoming hard to keep up, then you can use Workers for Platforms.
Think of any SaaS app that has webhooks to notify users of events, and an API for automations to respond to those events. For example:
* Chat service -> Chat bots
* Forums -> Moderator bots
* Spreadsheet editor -> User scripts to perform complex calculations when a cell changes
* Payments service -> Hook to send an invoice upon a successful monthly payment
Today, for a user to receive those webhooks, they have to run a server somewhere. Maybe on Digital Ocean or the like. That's easy if the user is itself a SaaS service, but it's a high hurdle for many other users.
Imagine instead that they could just upload JavaScript directly to the SaaS service, and it'd be run by the service in place of sending a webhook.
But most SaaS app developers don't want to be in the business of trying to run code on behalf of their users. Security and efficiency are both pretty difficult to get right.
Workers for Platforms lets the SaaS developer leverage Cloudflare Workers to do this. Cloudflare understands how to run arbitrary code security and efficiently.
So now, the SaaS developer can offer their users the ability to upload code snippets to automate events.
(Disclosure: I'm the tech lead of Cloudflare Workers, and I'm personally very excited about this product!)
Congrats on the launch! This is something we plan on adding to the Svix webhooks service[1], and we'll definitely take a look at cloudflare when doing it.
Awesome idea, and awesome product! The blog post mentions CF for SaaS will have these features as well. Does that mean if I have primarily SaaS customers, I can expose this feature to their custom domains as an addon?
It’s quite frustrating as a Cloudflare fan to read many of their blog posts and just not understand what they are promoting.
This post is an example, where I’m a developer, I just want to get to the concrete nuts and bolts. But we start off at a very high level, the problem often sounds a bit generic, and then it zooms into an example I just don’t get, I don’t have anything to compare it to or a concrete, real world example.
I don’t know if the Cloudflare blog has an editor, but I feel it needs one. There’s a lot of posts and I feel I have to trawl through to find the nuggets. The actual work that is produced is great, I just often don’t get how it is told through the blog.
I agree with this post, I didn't really understand it. Eventually I read the Shopify example, which helps a little bit: let Shopify's users create their own programmable storefronts.
It reminds me a little bit of Stripe Connect. I need more examples.
Put really concisely: you want to add serverless functions to your own SaaS platform. This is how you do it.
Expanded: Imagine (e.g.) a first-party Slack or Discord "Functions" offering, or a CRM tool (e.g. "Notion Functions") that allows you to consume + handle events directly as a user. Don't need to ask your users to sign up for, configure, maintain, (etc) $SERVERLESS_PLATFORM on their own, outside of your product. Give them an editor, do your own pre/post hooks, and plumb through relevant metadata that they can consume in their functions out-of-the-box.
(Disclaimer: work at Cloudflare, not on Workers, feedback on blog content is helpful)
Thank you, that tweet thread was really helpful. “Functions as a Service as a Service” maps it into familiar language I use today. Whereas “making every application on the Internet more programmable” sounds unrealistic (every application) and is pretty vague.
The latter is like an aspirational goal that the team has, which is fine if that’s what motivates you, but as a customer it’s not what motivates me. What motivates me is the problems I have.
“Making every application on the Internet more programmable” is actually a bit off-putting because it reminds me of the aggression of Microsoft and their "A computer on every desk and in every home." Bill Gates wrote it in internal memos. It’s not the words they used in their marketing campaigns.
My pithy advice for the blog would be: Keep the motivational quote on the team’s wall and in the team’s memo, and find out what customers have on their wall and are writing in their memos.
Glad that this sort of feedback on the blog is welcome, because it could be really good. Information architecture with the strange categories is another thing that’s confusing btw.
It just seems to be a management platform to allow you to deploy and track the runtimes of an unlimited number of Workers (i.e. functions) that operate in a tenant-isolated manner.
This is surprisingly easy to do with AWS Lambda right now, even though you need to understand the security implications and mitigate them to make this work safely. You just have to look at the Twilio functions implementation to see how someone achieves this at scale today. But having a prebuilt solution designed specifically for this is promising.
It's a good idea though, but yet another blog article with no info on pricing and the only way to access it is by going to Cloudflare cap-in-hand to ask politely. Who knows when (or if) this will ever become publicly available or be cost-effective long-term.
It's true you can do something similar with Lambda, but our architecture is much better suited to do this efficiently, especially in the case of scripts that aren't invoked very often.
This is a new product in the very early stages, which requires a high-touch feedback cycle with our early customers. You can expect once it's further along, you'll be able to sign up for it without talking to us first, and the pricing will be better than Lambda.
So each user of my SasS can have its own set of scripts? How big can each one of these scripts be? Can this script run wasm like normal workers? Can I embed data in it, like a serialized sqlite?
How fast is the startup of these scripts? Is it like a Cache read or more like a KV Store read?
18 comments
[ 1.3 ms ] story [ 47.5 ms ] threadIs it a way to activate and orchestrate workers based on a pub/sub message structure?
What's the benefit? You don't need to set this up yourself (security, authentication, validate tokens, create endpoints).
Why don't create an API so we have more control rather than give customers the ability to run any code? Well, it depends. If you can keep up with customer requests, then go ahead with an API. If you have a lot of requests and it's becoming hard to keep up, then you can use Workers for Platforms.
Think of any SaaS app that has webhooks to notify users of events, and an API for automations to respond to those events. For example:
* Chat service -> Chat bots
* Forums -> Moderator bots
* Spreadsheet editor -> User scripts to perform complex calculations when a cell changes
* Payments service -> Hook to send an invoice upon a successful monthly payment
Today, for a user to receive those webhooks, they have to run a server somewhere. Maybe on Digital Ocean or the like. That's easy if the user is itself a SaaS service, but it's a high hurdle for many other users.
Imagine instead that they could just upload JavaScript directly to the SaaS service, and it'd be run by the service in place of sending a webhook.
But most SaaS app developers don't want to be in the business of trying to run code on behalf of their users. Security and efficiency are both pretty difficult to get right.
Workers for Platforms lets the SaaS developer leverage Cloudflare Workers to do this. Cloudflare understands how to run arbitrary code security and efficiently.
So now, the SaaS developer can offer their users the ability to upload code snippets to automate events.
(Disclosure: I'm the tech lead of Cloudflare Workers, and I'm personally very excited about this product!)
[1] https://www.svix.com
This post is an example, where I’m a developer, I just want to get to the concrete nuts and bolts. But we start off at a very high level, the problem often sounds a bit generic, and then it zooms into an example I just don’t get, I don’t have anything to compare it to or a concrete, real world example.
I don’t know if the Cloudflare blog has an editor, but I feel it needs one. There’s a lot of posts and I feel I have to trawl through to find the nuggets. The actual work that is produced is great, I just often don’t get how it is told through the blog.
It reminds me a little bit of Stripe Connect. I need more examples.
Put really concisely: you want to add serverless functions to your own SaaS platform. This is how you do it.
Expanded: Imagine (e.g.) a first-party Slack or Discord "Functions" offering, or a CRM tool (e.g. "Notion Functions") that allows you to consume + handle events directly as a user. Don't need to ask your users to sign up for, configure, maintain, (etc) $SERVERLESS_PLATFORM on their own, outside of your product. Give them an editor, do your own pre/post hooks, and plumb through relevant metadata that they can consume in their functions out-of-the-box.
(Disclaimer: work at Cloudflare, not on Workers, feedback on blog content is helpful)
The latter is like an aspirational goal that the team has, which is fine if that’s what motivates you, but as a customer it’s not what motivates me. What motivates me is the problems I have.
“Making every application on the Internet more programmable” is actually a bit off-putting because it reminds me of the aggression of Microsoft and their "A computer on every desk and in every home." Bill Gates wrote it in internal memos. It’s not the words they used in their marketing campaigns.
My pithy advice for the blog would be: Keep the motivational quote on the team’s wall and in the team’s memo, and find out what customers have on their wall and are writing in their memos.
Glad that this sort of feedback on the blog is welcome, because it could be really good. Information architecture with the strange categories is another thing that’s confusing btw.
This is surprisingly easy to do with AWS Lambda right now, even though you need to understand the security implications and mitigate them to make this work safely. You just have to look at the Twilio functions implementation to see how someone achieves this at scale today. But having a prebuilt solution designed specifically for this is promising.
It's a good idea though, but yet another blog article with no info on pricing and the only way to access it is by going to Cloudflare cap-in-hand to ask politely. Who knows when (or if) this will ever become publicly available or be cost-effective long-term.
This is a new product in the very early stages, which requires a high-touch feedback cycle with our early customers. You can expect once it's further along, you'll be able to sign up for it without talking to us first, and the pricing will be better than Lambda.
We currently do something like: post code to a serverless function -> function executes code and returns output as HTTP.
This works but it's hard & requires a lot of adapter code (things like async errors).
I'd really like to talk about this - I understand that might not be possible. I filled in the form, any idea when we might hear something?
Do you support arbitrary npm modules?
How fast is the startup of these scripts? Is it like a Cache read or more like a KV Store read?
Yeah how about no. They pulled the same nonsense with R2 storage. Unless you're a known enterprise user, nobody is going to reply.