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.
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)
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.
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!)
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.
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?
[+] [-] burntcaramel|3 years ago|reply
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.
[+] [-] elithrar|3 years ago|reply
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)
[+] [-] singhrac|3 years ago|reply
It reminds me a little bit of Stripe Connect. I need more examples.
[+] [-] mathiasrw|3 years ago|reply
Is it a way to activate and orchestrate workers based on a pub/sub message structure?
[+] [-] kentonv|3 years ago|reply
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!)
[+] [-] giovannibenussi|3 years ago|reply
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.
[+] [-] kondro|3 years ago|reply
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.
[+] [-] kentonv|3 years ago|reply
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.
[+] [-] vzaramel|3 years ago|reply
How fast is the startup of these scripts? Is it like a Cache read or more like a KV Store read?
[+] [-] fjfbsufhdvfy|3 years ago|reply
Yeah how about no. They pulled the same nonsense with R2 storage. Unless you're a known enterprise user, nobody is going to reply.
[+] [-] rozenmd|3 years ago|reply
[+] [-] wasd|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]